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Chapter 1 — Introduction 



WHAT IS ADAMS 


The AIRLAB Data Management System (ADAMS) is an online environment that 
supports research at NASA's AIRLAB. ADAMS provides a number of custom 
functions that ease the task of documenting experiments and improve communica- 
tion among project members. This User’s Guide tells how ADAMS’ shared data 
capability can be used to manage research information and resources. Its organi- 
zation makes it effective as both a tutorial for the new user and a reference 
manual for the experienced user. 

ADAMS was developed for NASA Langley Research Center under the direction 
of Linda A. Hunt. The original design and prototype were developed by Founda- 
tion Computer Systems Incorporated under subcontract to Research Triangle 
Institute. The final version was designed by Linda A. Hunt, Linda Lauterbach, 
John L. Pierce and Randy Buckland and coded by Randy Buckland of the Center 
for Digital Systems Research at RTI. 

ADAMS resides on AIRLAB’s Digital Equipment Corporation (DEC) VAX 
11/780, known as System 1 (DECnet node name AIR1). It runs under the 
VAX/VMS operating system and uses the ORACLE database management sys- 
tem. A supporting computer network allows ADAMS to be run from any AIR- 
LAB VAX. Die ADAMS system is designed for simplicity, so interactions with 
the underlying data management system and co mmuni cations network are hidden 
from the user. ADAMS runs on standard DEC terminals like the VT-52, VT-100 
and VT-200 series, or any terminal that emulates a DEC terminal. 
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WHO SHOULD READ THE ADAMS USER’S GUIDE 


ADAMS was designed as a support tool for AIRLAB research project managers 
and project members who need to keep track of personnel, software, hardware, 
experiments and other project-related information. It provides flexibility for docu- 
menting project resources and activities and security for restricting access to confi- 
dential or proprietary project data. Although ADAMS can be used to document 
personal activities, its real power lies in the ability to share information with other 
members of project groups. Any AIRLAB project personnel who need the 
increased control over a project’s resources and activities which results from effec- 
tive documentation should examine the ADAMS User’s Guide to see how 
ADAMS can document and support their projects. 

The ADAMS User’s Guide provides a complete description of ADAMS functions 
and a tutorial and case study that show how ADAMS can be used to support 
research projects at AIRLAB. The new ADAMS user can begin to use ADAMS 
to support his or her research efforts efficiently by studying the material in the 
User’s Guide in the order suggested in the next section. Numerous cross- 
references in the text, a Glossary, an Index and several Appendices provide quick 
access to information in the Guide for the more experienced user. 
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HOW TO USE THE ADAMS USER’S GUIDE 


The new user should read the User’s Guide sequentially. The early chapters 
present a high-level overview of ADAMS and a tutorial to help the novice build a 
conceptual model of how ADAMS works. An Appendix lists the meaning of all 
diagnostic messages along with the action to be taken in response to a message, 
so the novice can quickly recover from error conditions caused by an incomplete 
understanding of the system. The following reading order is suggested: 

1. Examine the Table Of Contents to get a feeling for the overall structure of 
the User’s Guide. All sections are one or two pages long and are explicitly 
entitled to make ADAMS topic location easy. Note the Appendices, Glos- 
sary and Index, which are useful for looking up additional information and 
definitions during an ADAMS session. 

2. Read the first three chapters of the User’s Guide through Interacting With 
The ADAMS System. These chapters explain what ADAMS does, how the 
ADAMS interface works and how ADAMS can be used to support 
research projects at AIRLAB. 

3. Read Chapter 4, Tutorial: A Tour Through The ADAMS System. Once you 
are comfortable with the contents of the Tutorial, logon to VAX/VMS and 
work through the Tutorial to get a feeling for the ADAMS interface. The 
Tutorial provides a quick and easy introduction for the novice and illus- 
trates ADAMS’ major features. If you don’t know how to logon, read the 
section in Chapter 2 entitled ADAMS And The VAX/VMS Operating System. 

4. Now you’re ready to study the functions performed by ADAMS in greater 
detail. Read Chapters 5 and 6, ADAMS Database Operations and ADAMS 
Maintenance Operations. They explain each function performed by 
ADAMS in detail and provide sample terminal screens that illustrate 
ADAMS usage. Note that the contents of Chapter 6 are of interest pri- 
marily to project and system managers. 

5. Finally, go back through the User’s Guide and reread any sections you 
may not have fully understood. If you still have questions, contact some- 
one at AIRLAB who is already an experienced ADAMS user. Now you 
are ready to use ADAMS as a research support tool. 

The experienced user will use the Table Of Contents , Index and Appendices to 
locate topics of interest. Pointers to supplementary information are scattered 
throughout the text to increase the Guide’s usefulness as a reference tool. A 
Quick Reference Card also has been provided for quickly locating mnemonic 
names and meanings during an ADAMS session. 

Online field help provides short descriptions of the data to be entered at a partic- 
ular screen location. A help menu lists all keypad key functions and provides an 
overview of ADAMS menu structure. 
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CONVENTIONS USED IN THE ADAMS USER'S GUIDE 


References to other documents and to sections and chapters in the ADAMS 
User’s Guide are in italics. Section titles are presented in bold face; each section 
begins at the top of a new page and illustrations (if any) are on the right-hand 
side. Sections are short and self-contained to minimize the amount of flipping 
back and forth while using the Guide. Each chapter’s pages and illustrations are 
numbered individually with a hyphen separating the chapter number and page or 
illustration number (e.g., page 2-10 is the tenth page in Chapter 2 of the User’s 
Guide). The chapter title is printed at the bottom of each page. 

In ter min al screen examples and sample ADAMS te rmin al sessions, information 
entered by the user is in bold face. The cursor position is represented by a small 
square. Special terminal key names are enclosed in angle brackets; for example: 

<RET> = Return key 

<BACK> = Back Space key 

<PF1>keypao = The gold key also referred to as <G> 
(Programmable function key 1) 

Note: Die keypad subscript on the last example indicates the key is part of the 
numeric keypad at the right-hand side of the terminal keyboard. 
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ADDITIONAL SOURCES OF INFORMATION 


An ADAMS Quick Reference Card has been provided to aid the experienced user 
during an ADAMS terminal session. Also, ADAMS provides online help which 
describes field contents and keypad key functions. See the sections on ADAMS 
menus and display screens in Chapter 2 for a description of the help function. For 
additional help in solving problems with ADAMS, contact ADAMS maintenance 
personnel at AIRLAB. If possible, ADAMS trouble reports should be submitted 
using the software trouble report screen in the ADAMS Software/Hardware Unit 
submenu (see Chapter 5 for a full description of this submenu). 

There are several additional documents that may be of help to the ADAMS user: 

• ADAMS Programmer's Maintenance Manual — Tells AIRLAB ADAMS 
maintenance personnel how to fix a problem in the ADAMS system. This 
manual is not required by the general ADAMS user. 

• ADAMS Quick Reference Card — Provides lists of screen mnemonics and a 
diagram of the ADAMS menu system for quick reference during an 
ADAMS session. 

• ADAMS System Operator’s Guide — Tells AIRLAB ADAMS maintenance 
personnel how to install and maintain the system database files. This 
manual is not required by the general ADAMS user. 

• AIRLAB Research Support Capabilities — An inventory and description of 
hardware and software resources that support AIRLAB research. 

• AIRLAB User's Guide — Provides new users with an introduction to 
AIRLAB’s hardware and software. Tells how to get things done and sup- 
plies pointers to other documents. 
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GETTING ONLINE HELP DURING AN ADAMS SESSION 


Two kinds of online help are available in ADAMS — Field help and Main Menu 
help. 

Field help gives a status message regarding valid inputs for the field that the cur- 
sor is positioned on. Field help is invoked by pressing <PF2>keypad. The mes- 
sage appears in the bottom left-hand comer of the screen. 

Main Menu help is dividied into two submenus — Menu Tree and Keypad Key. 

• Menu Tree displays ADAMS (sub)menu relationship (see Appendix B - The 
ADAMS Tree Structure for a more detailed figure). 

• Keypad Key defines all keypad and cursor movement functions. 

Menu help is invoked on menu and action screens by pressing <PF2> keypad 
twice. On report screens you need to press <PF2> keypad only once. 

All diagnostic messages other than help messages are defined in Appendix A - 
Status and Error Messages. 
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Chapter 2 — An Overview Of the ADAMS System 



THE PROJECT DATABASE CONCEPT 


The ADAMS shared database allows project groups to store shared information 
documenting project activity. Each person in a group can browse, add, update, 
and delete personal and shared information in several categories: 

• Persons contributing to a project 

• Status of experiments performed under a project 

• Organizations involved in a project 

• AIRLAB hardware and software contributing to a project 

• Manuals, technical papers, and other documentation 

• Active and archived project data 

• Shared and private notebook entries 

The ADAMS security validation system protects critical project data from 
accidental or intentional modification. Access to data depends on the user’s secu- 
rity level and project group membership as determined by the project leaders and 
system managers. 

System managers, project leaders, and project group members access project data 
through the ADAMS user-friendly interface ( Figure 2-1); before data records are 
accessed by the database manager software, the security validation software 
checks to make sure the person requesting the data has permission to access it. 
The validation and data retrieval processes are hidden from the user. All tran- 
sactions are mediated by the menu-driven ADAMS interface. This makes the 
database browsing, adding, updating, and deleting functions easy to learn for the 
beginner and flexible for the expert. 
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Figure 2-1. The ADAMS System 
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HOW ADAMS SUPPORTS AIRLAB PROJECT MANAGEMENT 


There are three kinds of ADAMS users: the system manager, who is responsible 
for maintaining the ADAMS system and system-wide data; the project leader, 
who is responsible for managing one or more groups of personnel working on a 
project; and group members, who are performing work under a project leader’s 
guidance. The project leader defmes groups under a project and associates group 
member accounts with the groups. A set of group keywords can be established to 
tag information for later retrieval. The ADAMS project/group security system 
establishes a data access hierarchy which a project leader can use to segregate 
project documentation by personnel group functions within a project. 

ADAMS project data storage and retrieval capabilities allow project leaders and 
group members to: 

• Keep track of all resources associated with a project, including software, 
hardware, people, institutions, and data. 

• Make online notebook entries that describe experimental work and docu- 
ment project software bugs and fixes. 

• Start ADAMS when logging in at the beginning of a terminal session, 
escape to VAX/VMS to do software development or other research support 
work under VMS, then return to ADAMS to document the work done. 

ADAMS creates a research support environment that captures ongoing work on 
AIRLAB experiments with a small amount of effort on the part of project 
members and allows documentation of completed work to be examined 
throughout the project life cycle. Immediate benefits of using ADAMS include 
increased control over all phases of an experiment for a project’s leader and 
increased visibility into ongoing work for a project’s contract monitor. The 
improved project documentation that results from using ADAMS eases transitions 
when personnel change. This makes restarting complex suspended experiments or 
redoing data analyses easier in the long run since experiment data, analyses, and 
notebook entries can be easily retrieved. 

The cost of using ADAMS is, of course, the effort and discipline involved in 
using a new system for documenting work. ADAMS replaces the traditional 
engineer’s or experimenter’s notebook with an online, keyword-oriented system. 
Notes can be quickly made as an experiment proceeds and tagged with single or 
multiple keywords for fast retrieval later in the project. The payoffs discussed in 
this section make the startup cost of learning to use ADAMS worthwhile. 
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ADAMS AND THE VAX/VMS OPERATING SYSTEM 


The ADAMS system has been designed so minimal interaction with the 
VAX/VMS operating system is necessary. You need to know how to use your ter- 
minal, how to access AIRLAB computers, and how to logon and logoff 
VAX/VMS. The EDT editor can be invoked to edit notebook entries from 
ADAMS by pressing <9>keypad, but knowledge of EDT is not really needed to 
use ADAMS productively. New AIRLAB users should refer to the AIRLAB User’s 
Guide and the AIRLAB Research Support Capabilities document for information on 
obtaining an account on VAX/VMS and on learning to use the system. 

There are a couple of VAX/VMS files that might appear under exceptional cir- 
cumstances: 

netserver.bg Appears on AIR1 if ADAMS is invoked from another AIRLAB 
computer and there is a problem. This file can be deleted with the 
VAX/VMS DELETE command. 

username, tmp Appears under the current file directory if the EDT editor is 
invoked while making a notebook entry and a system failure 
occurs. This file can be deleted with the VAX/VMS DELETE 
command. 
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THE ADAMS SECURITY SYSTEM 


ADAMS provides three security levels for the control of access to project data. 
User account security levels are identified by a single letter field in the Mainte- 
nance Operations/Security/Access Level submenu. These identifiers are listed in 
parentheses in the following descriptions: 


System (S) 


Project (P) 


Group (G) 


A user whose account has system level privileges can access any 
data in the ADAMS system and grant access to ADAMS to 
other users. The only AIRLAB personnel who have system level 
privileges are the persons responsible for maintaining ADAMS. 
Siystem level data is typically information that rarely changes or 
that is critical to the functioning of the entire ADAMS system 
(e.g., data on personnel or institutions involved in AIRLAB 
research). 

A user whose account has project level access can deactivate and 
reactivate projects, define and undefine group keywords, and 
assign and deassign users to project groups. AIRLAB personnel 
who have project level privileges are usually project managers 
or leaders who are responsible for one or more groups of experi- 
menters, programmers, or other personnel working on research 
experiments. The only data associated specifically with the pro- 
ject level is the project name, which is defined by the system 
manager when a project is established from the Security sub- 
menu (described in Chapter 6). 

A user whose account has group level access can create and 
access data that is sharable by all members of the group, use 
group keywords, and create and access personal data. AIRLAB 
personnel who have group level privileges are usually experi- 
menters, programmers, contract monitors, or other personnel 
working in one or more groups under a project leader. Group 
level data is typically information that is of interest to all 
members of a group working on an experiment. Examples are 
software trouble reports and their resolution, and information on 
the location of raw and processed experimental data. 


The access level associated with individual database records depends on the secu- 
rity level and group membership of the user who created the record, and on the 
nature of the data. The types of access that are permitted to specific ADAMS 
screens are discussed in greater detail in Chapters 5 and 6. Figure 2-2 illustrates 
the branching structure of the ADAMS security system. Note that the system 
manager typically works at the system and project levels when creating and 
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deleting database information, and the project leader works at the group and indi- 
vidual group member levels. Both groups in the illustration have sets of keywords 
associated with them which can be used by the group members or project leader 
for tagging database entries for later retrieval. Each user in the security system 
also has a number of private keywords associated with his account for ta g gin g and 
retrieving personal research entries in the database. 


System (S) 




Project (P) 


System 

Manager 



I 


Project 

Leader 



Figure 2-2. ADAMS Database Security Levels 
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MENU SCREEN FORMAT AND COMMANDS 


Menu screens are used to maneuver through the tree-like ADAMS menu system 
to reach an action screen, where database records can be created or retrieved for 
browsing, updating or deleting. The structure of a menu screen is illustrated on 
the opposite page. The options on a menu screen are listed in the middle of the 
screen. To choose an option, type the option’s number at the keypad or type the 
number at the regular keyboard followed by <RET>. The system responds by 
moving to an action screen or to another menu with a new set of options. 

Every screen except the Logon screen has a mnemonic name. The mnemonic 
names for action screens begin with B, A, U, or D for Browse, Add, Update, or 
Delete and end with AS. The mnemonic names for menu screens end in MN. 
Screen mnemonics are listed alphabetically in Appendix C. You can jump to any 
menu or action screen from a menu by entering the mnemonic name of the desti- 
nation screen at the prompt. For example, if the destination is the Browse Con- 
tributor screen, type B_CONT_AS <RET> or B_CONT_AS <Enter> keypad at 
the prompt. You can type hyphens (-) instead of underscores (_). The system 
responds by moving directly to the Browse Contributor screen. You cannot jump 
from an action screen to a menu screen. When you exit the screen you jumped 
to, ADAMS returns to the menu screen you were at when you executed the jump. 

The commands for menus appear in the rectangular box at the bottom half of the 
screen; they must be entered from the keypad. These commands are: 


Commands 

Definitions 

<Enter> = Do 

Executes valid actions for menu screens 
(See below) 

<PF2> = Help 

One line help or help screens 

<0> = Exit Screen 

Move back one screen 

<.> = Make Note 

Move to notebook entry 


The main menu has only <Enter>, <PF2>, and <.> commands. The 
< Enter > c omm and on menu screens executes mnemonic names to jump directly 
from a menu to an action screen or another menu. 
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ACTION SCREEN FORMAT AND COMMANDS 


Action screens are used to create and manipulate database records. Action 
screens are grouped by the four types of database functions: 

• Browse Browse currently existing records 

• Add Add a new record into the database 

• Update Update currently existing records 

• Delete Delete currently existing records 

See Chapter 3 — Interacting with the ADAMS System, for detailed explanations 
regarding these functions. 

The structure of an action screen is illustrated on the opposite page. Action 
screen commands appear in the rectangular box on the bottom half of the screen; 
they must be entered from the keypad. These commands are: 


Commands 

Definitions 

<Enter> = Do 

Executes valid actions for each action screen 
(See below) 

<PF2> = Help 

One line help or help screens 

<0> = Exit Screen 

Move back one screen 

<Up> = Prev line 

Move to previous line in a scrolling region 
Move to previous page in a paging region 

<Down> = Next line 

Move to next line in a scrolling page 
Move to next page in a paging region 

<7/8> = Print 

Print the record. 7 prints the record. 
8 prints from current to last record 
in the working set. 

<G-0> = Open line 


<FF4> = Kill line 

Deletes the line the cursor is on 


The action of < En ter > keypad depends on the current database function: 

• Browse Retrieves the record(s) requested 

• Add Adds the new record to the system 

• Update Retrieves the record(s) to be updated 

Stores the updated version(s) 

• Delete Retrieves the record(s) to be deleted 

Deletes the retrieved record(s) 

Refer to Appendix C — Mnemonics Names, for a list of all action screen mnemon- 
ics. 
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REPORT SCREEN FORMAT AND COMMANDS 


Report screens display records that are stored in the database. When you request 

a record at any action screen, the result is a report screen. 

There are three types of report screens: 

1) A report screen that displays all information after single or multi-line fields 
as shown in the first figure on the opposite page. 

2) A report screen that has scrolling regions — either one or two rectangular 
boxes that scroll — and single or multi-line fields, as shown in the second 
figure on the opposite page. The field name for a scrolling region is located 
at the top left-hand comer of the rectangular box. When there are two 
scrolling regions (e.g., Software Trouble Report), the field name will be in 
reverse video to indicate which box the cursor movement keys are active in. 
Press the <2>kevpad to move the cursor to the previous scrolling region and 
the <1>kevpad to move the cursor to the next scrolling region. Use the 
arrow keys to scroll text in the current scrolling region. 


(continued on page 2-14) 
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3) A report screen that has both scrolling regions and paging regions and single 
and/or multi-line fields, (e.g. , Inhouse Software) or just paging regions along 
with single or multi-line fields (e.g., Hardware Unit). Paging regions are 
identified by brackets [ ] that surround the area. The figure on the opposite 
page includes a paging region. Press the <2>keypad to move the cursor to the 
previous scrolling or paging region and the <1>keypad to move the cursor to 
the next scrolling or paging region. Use the arrow keys to page or scroll in 
the current paging or scrolling region. 

Report screen commands appear in the rectangular box on the bottom half of the 
screen; they must be entered from the keypad. These commands are: 


Commands 

Defintions 

< Enter > = Do 

Move back one screen 

<PF2> = Help 

One line help or help screens 

<0> = Exit Screen 

Move back one screen 

<7/8> = Print 

Print the record. 7 prints the record. 
8 prints from current to last record 
in the working set. 

<-> = Prev Record 

Return to previous report screen 

<Up> = Prev line 

Move to previous line in a scrolling region 
Move to previous page in a paging region 

<Down> = Next line 

Move to next line in a scrolling region 
Move to next page in a paging region 

<,> = Next Record 

Move to next report screen 


The following additional commands can be used on report screens. 


Command 

Definition 

E53EE55IH 

Move back in text one scrolling region 

<PF1> <Down> 

Move forward in text one scrolling region 
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Chapter 3 — Interacting With the ADAMS System 



ENTERING AND LEAVING ADAMS 


To log on to ADAMS, type ADAMS <RET> in upper or lower case after the 
VAX/VMS prompt (See AIRLAB User's Guide and Research Support Capabilities 
for instructions on using VMS). If you do not have permission to use ADAMS, 
you will receive the message ‘Error accessing ORACLE database’. If you have 
permission, the ADAMS Logon screen will appear. The logon screen can be used 
to enter text describing the session’s purpose. After optionally entering the pur- 
pose, press <RET> or < Enter > keypad. The main menu automatically appears. 
Now you are ready to begin the ADAMS session. 

System messages appear at the bottom left-hand corner of the screen. A typical 
system message is ‘invalid key selection’ — which means the key typed is not 
valid in this context. ADAMS status and error messages are listed alphabetically 
in Appendix A. 

To log off, you can either go to the main menu and select option 4, Logoff, to get 
to the Logoff screen or you can go directly to the logoff screen by typing LOG- 
OFF <RET> from any menu screen. The Logoff screen can be used to enter 
any final remarks about your ADAMS session. (After optionally entering final 
remarks, press <RET> or <Enter> keypad. The screen will clear and the VMS 
prompt will appear at the bottom of the screen). 


Interacting with the ADAMS System, p. 3-1 



USING THE TERMINAL KEYBOARD AND KEYPAD 


The entire keyboard is divided into a regular keyboard which looks like a type- 
writer keyboard and a keypad which contains the numerals and command keys 
(i.e., <PF1>keypad, <PF2> keypad, <Enter> keypad). The keypad is at the right- 
hand side of the keyboard. The regular keyboard is used to enter input at field 
prompts on action screens. The regular keyboard can also be used to select 
options on menu screens. <RET> must be pressed to select a menu option from 
the regular keyboard. 

The keypad is used to select options on menu screens. <RET> does not have to 
be pressed when a keypad key is selected. Commands are also entered from the 
keypad. For example, the command ‘Make Note’ is invoked by pressing 
<.>keypad on the keypad. The figure on the opposite page lists all keypad key 
functions. 
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Help Keypad 


A Prev 
Line 
+ Page 

V Next 
Line 
• Page 

< 

Left 

> 

Right 


Keys 

Enter = Enter form 
Return = Next field 
Backspace = Prev field 
Linefeed = Erase field 
Delete = Delete character 


Zero = Back Up 
Enter = Exit Help 


Gold 

Help 

Field 

Help 

Overstk 

Insert 

Kill 

Line 

7 

Print 

8 Print 
All 

9 Enter 
Edt 

Prev 

Screen 

4 Find 
Next 
Search 

5 

6 

Next 

Screen 

1 Prev 
Region 

2 Next 
Region 

3 

Do 

Back Up Menu 
Open Line 

Note 

Make 

Key- 

word 


Keypad key function names in italics are gold functions. Gold functions are 
invoked by pressing <PF1>keypad (the gold key) before the function key. 

Note: Some functions are only valid on certain screens. 
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HOW TO INPUT DATA ON ADAMS ACTION SCREENS 


The previous section discusses use of the regular keyboard and the keypad for 
ADAMS input. To move through the fields on action screens, press <RET> 
except when entering a paging or scrolling region. Scrolling regions are indicated 
by rectangular boxes on screens. The field name for a scrolling region is located 
at the top left-hand comer of the rectangular box. Paging regions are indicated 
by left [ and right ] surrounding the paging region. To move to one of these 
regions, press <1>keypad. Do not press <RET> after typing in the last entry in 
a paging or scrolling region or the system expects more data and will not write 
the record. 

By default you are in overstrike mode, when typing text in ADAMS. This means 
you can type over any information you have previously typed. If an error is 
made when entering information, the left and right arrow keys move the cursor 
left and right within the field and <BACK> moves the cursor back to the previ- 
ous field so the error can be corrected. <Delete> deletes the character to the 
left of the cursor only when the cursor is on the blank space at the end of the 
line. <Line Feed> deletes the contents of the field that the cursor is on. 

By pressing <PF1>keypad <PF3>keypad, you can enter insert mode to enter text 
midway in a line (all characters to the right of the cursor will move to the right). 
<Delete> deletes the character to the left of the cursor anywhere in the line. 
<Line Feed> deletes the contents of the field the cursor is on. Pressing 
<PF3> keypad takes you from insert mode back to overstrike mode. 

The phone field for the categories Contributors and Institutions has the format 
( ) - . The cursor jumps over the parentheses and the hyphens when a 

phone number is being entered. 

The operators < (less than), > (greater than), and - (hyphen), can be used to 
specify ranges of dates on action screens. For example, 

< 01/01/84 all records before January 1, 1984 

> 01/01/84 all records on or after January 1, 1984 

01/01/84 - 01/01/85 all records from and including January 1, 1984 

through January 1, 1985 

Since ADAMS does not have auto wrap on action screens, you must press 
<RET> when you come to the end of the line in a scrolling region to get to the 
next line. 

When entering information in the Group field on action screens, you must enter 
the names of one or more groups. To view the list of existing groups, press 
<PF1>keypad <PF2>keypad. 
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SETTING UP TEMPLATES FOR DATA RECORD RETRIEVAL 


The browse, update, and delete functions operate on a working set of database 
records that are retrieved using a search template containing field values that 
qualify the search. There are separate action screens for each function type. 
You can page through the working set once it has been retrieved to selectively 
examine, update, or delete records. 

A template specifies which record(s) will be retrieved. Only records with infor- 
mation matching the information you enter in template fields are retrieved. 
Enter information in template fields on an action screen, then press 
<Enter>«EYPAD to cause the record(s) to be retrieved. Fields can include: 

• numerical idents assigned when record was created by ADAMS 

• username of person who created the record 

• creation date(s), either explicit or qualified by operators 

• other fields specific to the type of record 

The result is a set of report screens to browse, update or delete, depending on the 
context. 
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THE BROWSE FUNCTION: EXAMINING ENTRIES 


Database records in ten subcategories under Database Operations and the three 
subcategories under Maintenance Operations can be examined with the browse 
function (See Appendix B — The ADAMS Menu Tree Structure for a description of 
ADAM’s menu structure). Records cannot be added, updated, or deleted while 
browsing. 

All existing records under a subcategory of Database Operations or Maintenance 
Operations or a subset of specific records can be retrieved for browsing by setting 
up a template to qualify the search (see the previous section on how to set up a 
template). To browse all records, press <Enter>KEYPAo on an empty template. 
To browse a specific set of records, set up a template 1 and press <Enter> keypad. 
The system reponds ‘Reading records’. If no records match the search criteria, 
the system responds with ‘No records found’. If records do exist, a report screen 
containing the first record will appear and a system message that contains the 
number of records placed in the working set will be displayed. 

Access to individual records depends on your account’s security level and the type 
of record. For a discussion of security levels, see Chapters 5 and 6. 


1 Set up the template by entering values in the field(s) that will restrict the data- 
base search to the records of interest. 
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THE ADD FUNCTION: CREATING ENTRIES 


The add function creates database records for all Database Operations except 
Notebook. Notebook entries are created with the command <.> keypad. The add 
function also creates database records for all Maintenance Operations except 
Logon and Logoff. Logon records are created when ADAMS is invoked, and 
Logoff records when ADAMS is exited. 

To add a new record, type data at the appropriate field prompts, then enter the 
information into the system by pressing <Enter>KEVPAo. The system replies ‘Writ- 
ing record’. Remember, there are scrolling and paging regions as well as single 
and multi-line input fields. To move to scrolling and paging regions, press 

<1> KEYPAD. 

By default you are in overstrike mode when typing text in ADAMS. To enter 
insert mode, press <PF1>keypad<PF3>keypad (see How to Input Data on ADAMS 
Action Screens in this chapter for a detailed explanation of each mode). 

Access to individual records depends on your account’s security level and the type 
of record. For a discussion of security levels, see Chapters 5 and 6. 
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THE UPDATE FUNCTION: MODIFYING ENTRIES 


The update function is valid for all ten Database Operations subcategories and 
three Maintenance Operations subcategories. Logon and Logoff information can 
be deleted but not updated. 

To update a record(s), one or more records must first be retrieved by setting up a 
template to qualify die database search. Once the records to be updated have 
been retrieved, the updated information is typed directly over the existing data if 
a field is full. 

By default you are in overstrike mode when typing text in ADAMS. To enter 
insert mode, press <PF1>keypad<PF3>keypad (see How to Input Data on ADAMS 
Action Screens in this chapter for a detailed explanation of each mode). 

Access to individual records depends on your account’s security level and the type 
of record. For a discussion of security levels, see Chapters 5 and 6. 
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THE DELETE FUNCTION: DELETING ENTRIES 


To delete a specific set of records, set up a template to qualify the search. After 
the records have been retrieved, press <Enter> keypad to delete the records. The 
system responds with *X records to be deleted. Do you want to do this?’. Enter 
Y <RET> to delete records, and the system responds with ‘Deleting records’. 
Enter N <RET> to terminate the deletion request (i.e., if an error has been 
made in setting up the search template). The system responds with ‘No records 
deleted’. To delete all of the records in a subcategory, press <Enter> keypad 
without setting up a template to retrieve the records and then press 
< Enter > keypad again to delete the records. The system responds with the same 
system message as given above. This is a safety measure to reduce the chances of 
accidentally deleting all records in the database. 

Access to individual records depends on your account’s security level and the type 
of record. For a discussion of security levels, see Chapters 5 and 6. 
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Chapter 4 — Tutorial: A Tour Through the ADAMS System 



A TUTORIAL: 

LOGGING ON AND INVOKING THE ADAMS SYSTEM 


To work through this tutorial, enter the information that appears in boldface on 
the sample screens. Sample screens are presented opposite the pages of text that 
describe them. Certain repetitive screens are not illustrated in the tutorial. 
These screens are flagged with a statement in the text. See the A1RLAB User’s 
Guide for more information on using VAX/VMS and terminals. Note: You 
should work through the tutorial from start to finish in a single terminal session. 

Logging on to VMS 

1. You begin the logon procedure by communicating with ( the Bridge.’ Press 
<RET>. The operating system will respond with User Name>. In 
response, enter GO Sn where n is the number of the computer you wish to 
use (i.e., SI = AIR1). The bridge will connect you to the specified com- 
puter. 

2. Now, log on to the VAX/VMS operating system by executing these two 
steps: 

a. Type your username <RET> after the Username: prompt. After 
accepting your username, the system displays a password prompt. 

b. Type your password <RET>. Notice that the system does not display 
the password; this is a security measure. If an improper username or 
password is entered, the system will respond with the message, ‘User 
authorization failure’. If this message appears, you must begin the logon 
procedure again. If the operating system recognizes the username and 
password, the VMS prompt “$’ appears. Contact your AIRLAB 
VAX/VMS system personnel if you can’t get your username and pass- 
word to work. 

Logging on to ADAMS 

1. Now log on to ADAMS by typing (in either upper or lower case) ADAMS 
after the VMS prompt. If you can’t get into ADAMS, contact the ADAMS 
system manager to become a validated ADAMS user. 

2. The ADAMS Logon screen appears. Type in the Purpose that is in boldface 
on the example screen on the opposite page. Press <Enter>KEVPAD or 
<RET> to get to the next screen. 

3. The Main Menu appears next. Choose option 1, Database Operations, as 
shown on the sample screen. A <RET> is needed if you type 1 on the key- 
board; no <RET> is needed if you type 1 on the numeric keypad. 

4. The next menu screen displayed is Database operations. Choose option 5, 
Documentation. This screen is not shown. 
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Unused Page 


A Tutorial, p. 4-2 




A Tutorial, p. 4-3 









A TUTORIAL: 

ADDING AN ENTRY TO THE DATABASE 


In this section you will add a Documentation record to the ADAMS database. 

Adding a Documentation Entry 

1. The Documentation menu screen is now on the terminal. Choose option 2, 
Add. 

2. The Add Documentation action screen is next. After completing all indi- 
cated fields on the screen, enter the information into the system by pressing 
<Enter> keypad. The system will respond with the message ‘Writing record’ 
and a fresh add screen will appear. Note: You will not be entering informa- 
tion at every field on the Documentation screen. 

3. To exit the add screen, press <0>keypad. Now choose option 1 on the Docu- 
mentation Menu screen. The second occurrence of the Documentation Menu 
screen is not shown. 
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A TUTORIAL: 

BROWSING THROUGH THE DATABASE 


In this section you will examine the Documentation record created in the previous 

tutorial section by invoking the browse function. 

Browsing a Documentation Entry 

1. The Documentation Selection action screen is now on the terminal. Enter AI 
DEMO for Subject to qualify the search. Then press < Enter > keypad to begin 
the search . The system responds with the message ‘Reading records’. 

2. The requested documentation report screen is displayed. The system 
responds with the message ‘1 record found’. 

3. To exit the report screen, press <0>keypad. You are now back to Documen- 
tation Selection. Press <0> keypad again to return to the Documentation 
Menu screen. Now choose option 3, Update, on the Documentation Menu 
screen. This screen is not shown. 
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ADAMS ^ 

Documentation Selection ] 

Doc Id: 
Vendor: 
Subject: 
Part Num: 
Hw/Sw: 

AlDEMOa 

Title: 

Remarks: 


Keywords: 



< Enter > = Do <PF2> = Help <0> = Exit Screen 


(BJXX^AS) 

L _ " J 



ADAMS 

Browse Documentation 


Ident: 

CT-001 


Vendor: 

COMPUTER TIMES 


Subject: 

AIDEMO 


Part Num* 

Hw/Sw: 

s 


Title: 

The Need for AI in Today's World 


Remarks: 

Keywords: 

[« i 



< Enter > = Do <PF2> = Help <-> = Prev Record 

<0> = Exit Screen <7/8> = Print < t > = Next Record 


1 record found 

(B_DOC_AS) 
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A TUTORIAL: 

UPDATING AN EXISTING DATABASE ENTRY 


In this section you will update the Documentation record created previously by 

invoking the update function. 

Updating a Documentation Entry 

1. The Documentation Selection action screen is now on the terminal. First, 
qualify the search by entering COMPUTER TIMES for Vendor. Then press 
<Enter>KEVPAD to begin the search. The system responds with the message 
'Reading records'. This screen is not shown. 

2. The update screen that has been requested is displayed. The system 
responds with the message '1 record found’. 

3. Now input the information that appears in boldface on the second sample 
screen. After completing the update, enter the updated record into the sys- 
tem by pressing <Enter> keypad. The system responds with the message 
‘updating record’. 

4. To exit this update screen, press <0> keypad. Now choose option 4, delete, 
on the Documentation Menu screen. This screen is not shown. 
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r 

ADAMS 1 

Update Documentation 

Doc Id: 

CT-001 

Vendor: 

COMPUTER TIMES 

Subject: 

AIDEMO 

Part Num: 

Hw/Sw: 

s 

Title: 

The Need for Alin Todays’ World 

Remarks: 

Keywords: 

I- i 

i 


< Enter > = Do <PF2> = Help <-> = Prev Record 

<0> = Exit Screen <7/8> = Print <,> = Next Record 


1 record found. (LLDOCLAS) 

v ) 


r 

ADAMS ' 

Update Documentation 

Doc Id: 

CT-001 

Vendor: 

COMPUTER TIMES 

Subject: 

AIDEMO 

Part Num: 

DEMO-732CT 

Hw/Sw: 

S 

Title: 

The Need for AI in Todays* World 

Remarks: 

Anywhere, USAn 

Keywords: 

[** i 


<Enter> = Do <PF2> = Help <-> = Prev Record 

<0> = Exit Screen <7/8> = Print <,> = Next Record 


1 record found (U_DOC_AS) 

V . 
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A TUTORIAL: 

DELETING AN EXISTING DATABASE ENTRY 


In this section you will delete the Documentation record you just updated. 

Deleting a Documentation Entry 

1. The Documentation Selection action screen is now on the terminal. Enter AI 
DEMO for the Subject field to qualify the search. Now press <Enter> keypad 
to begin the search. The system responds with the message ‘Reading 
records’. 

2. The report screen that has been requested is displayed. The system responds 
with the message ‘1 record found’. 

3. To delete this record, press <Enter>KEvpAD. The system responds with ‘1 
record will be deleted. Do you want to do this?’. Enter y to delete the 
record. The system responds with the message ‘Deleting records’. 

4. To exit Documentation Selection, press <0> keypad. Now choose the com- 
mand make note by pressing <•> keypad. This screen is not shown. 
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r 

ADAMS 1 

Documentation Selection 

Doc Id: 
Vendor: 
Subject: 
Part Num: 
Hw/Sw: 

AIDEMOO 

Title: 

Remarks: 


Keywords: 



< Enter > = Do <PF2> = Help <0> = Exit Screen 


(D_DOC_AS) 

V. J 



ADAMS 

Delete Documentation 


Ident: 

1 


Vendor: 

COMPUTER TIMES 


Subject: 

AIDEMO 


Part Num: 

DEMO-732CT 


Hw/Sw: 

S 


Title: 

The Need for AI in Today’s World 


Remarks: 

Anywhere, USA 


Keywords: 

i" i 



< Enter > — Do <PF2> = Help <-> = Prev Record 

<0> = Exit Screen <7/8> = Print <.> = Next Record 


1 record found (D_DOC_AS) 

- J 


A Tutorial, p. 4-11 






A TUTORIAL: 

ENTERING A NOTE IN THE ADAMS NOTEBOOK 


Entering a Note 

1. The Add Notebook Entry action screen is now on the terminal. The User- 
name, Group, Ident and Date fields are automatically generated by the sys- 
tem. Username is the account you used to log on to VAX/VMS. The 
default value of Group is PERSONAL but can be changed to any group 
you’re a member of. To delete PERSONAL, press <Linefeed>. To look 
at groups that can be entered in this field (besides PERSONAL), press 
<PF1>keypad<PF2>keypad. Ident is an integer that is automatically gen- 
erated when a new note is entered. Date is assigned the current date and 
time. 

2. The prompt is on Group. To move to the keyword field, press <RET>. 
Press <PF1>keypad (the Gold Key) <Enter>KEYPAD after entering the key- 
word, Flight. The PF1 and Enter keys are used only when entering new 
keywords. 

3. To add the note that is on the sample screen, press <1>keypad to enter the 
Text field. Now type from the regular keyboard to make your entry. 

4. To write the entry, press <Enter> keypad. The system responds with ‘Writing 
note’. You can write the entry while the cursor is still in the Text field. 

5. To exit Add Notebook Entry, press <0>keypad. 
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ADAMS 

Add Notebook Entry 


Username: JAS Keyword: I FLIGHT 

Group: PERSONAL 1 

Ident: 1 

Date: 06/17/85:15:24:31 


For application section, need to develop a complete example showing process 
of generating an interpreter: 

1. Grammar: extend BEXP to include functions on boolean expressions 

2. Rewrite rules: general OR, binary AND 

3. Consistency: check rewrite rules, identifying intersections of LHSn 


<Up> = Prev line <Enter> = Do <7/8> = Print <-> = Prev Screen 

<Down> = Next line <0> = Exit Screen <PF2> = Help <,> = Next Screen 


(A_NOTE_AS) 
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A TUTORIAL: 

LEAVING THE ADAMS SYSTEM AND LOGGING OFF 


Logging off of ADAMS 

1. The Documentation Menu menu screen is now on the terminal. This screen 
is not shown. 

2. Type LOGOFF or the abbreviation LO at the Enter choice prompt. 

3. The Logoff Screen appears on the terminal. Note that ‘Remarks’ is an 
optional field. Press <RET> to leave the ADAMS system. 

4. The ADAMS session is now complete, and you are now back to VMS. A *$’ 
prompt is displayed. Type lo to logoff VMS, or ADAMS to execute ADAMS 
again. 

Note: Now that you’ve worked through the tutorial, you may want to read Appen- 
dix D which describes how ADAMS was used to support a software reliability 

program at AIRLAB. 
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Chapter 5 — ADAMS Database Operations 



WHAT ARE THE DATABASE OPERATIONS 


The Database Operations menu contains several action screens and the following 
three submenus. 

1. Software/Hardware Units 

2. Archives 

3. Data 

The Database Operations actions screens are: 


Contributors 

Experiments 

Institutions 

Software Trouble Report 
Inhouse Software 
Vendor Software 
Hardware 

Documentation 
Personal Keywords 
Archive Medium 


AIRLAB personnel who use the ADAMS system or 
contribute to a project in some way. 

Research experiments under an AIRLAB project. 

Names of organizations or institutions that are con- 
ducting experiments at AIRLAB. 

Selected from a submenu under Software/Hardware 
Units. Descriptions of inhouse or vendor software 
bugs and fixes to them. 

Selected from a submenu under Software/Hardware 
Units. Software written at AIRLAB to support 
experiments. 

Selected from a submenu under Software/Hardware 
Units. Software purchased from vendors to support 
AIRLAB experiments. 

Selected from a submenu under Software/Hardware 
Units. Hardware that supports AIRLAB experi- 
ments that is either owned by AIRLAB or brought in 
by other institutions for research projects. 

User manuals, guides, etc. All types of documenta- 
tion for software or hardware, either written at AIR- 
LAB or vendor-supplied. 

list of keywords developed by the user for retrieving 
personal database entries. Group keywords are 
created and changed by the project leader. 

Selected from a submenu under Archives. Informa- 
tion about tapes, discs, and other storage media on 
which project riles either are archived or can be 
archived. 


Data Archive Selected from a submenu under Archives. Tells 

what data has been archived by which project 
members. Users may archive their own data; see the 
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Software Archive 


Processed Data 


Raw Data 
Technical Papers 


Notebook 


AIRLAB User’s Guide for details. 

Selected from a submenu under Archives. Shows 
when and to which device project support software 
was archived. 

Selected from a submenu under Data. Describes 
processed experimental data and the analyses that 
were performed during processing. 

Selected from a submenu under Data. Describes 
unprocessed experimental data. 

Contains bibliographic entries for technical papers of 
interest to a project’s members, including papers 
published by contributors, papers used as references 
during an experiment, and papers written as a result 
of an experiment. 

Experimenter’s or engineer’s notebook; personal and 
shared group notes written during an AIRLAB 
experiment. 


The Database Operations menu structure is illustrated as an inverted tree in 
Appendix B, which shows the Erst few levels of the branching system labeled with 
screen mnemonics. Appendix C provides a list of screen mnemonics and their 
definitions arranged alphabetically for reference. 

The general format and contents of menu, action, and report screens are dis- 
cussed in Chapter 2. Database record manipulation is discussed in Chapter 3. The 
manipulation of single line fields, multi-line fields, paging regions, and scrolling 
regions is discussed in the section How to Input Data on ADAMS Action Screens in 
Chapter 3. 
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Unused Page 
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SECURITY LEVELS AND DATABASE MANIPULATION 


The access permitted to ADAMS users with system (S), project (P), and group 
(G) privileges for the various Database Operations screens is described in the 
table on the opposite page. Each account permission column in the table is 
divided into Read and Write subcolumns. Read permission means a user can 
browse an entry in the screen, but not add new entries or change or delete exist- 
ing entries; Write permission means a user can browse, add, update, or delete 
entries in the screen. 

Four character codes indicate the amount of access permitted to a screen: 

X No access is permitted to this category. 

O Owner: only the username that created the data in this category may 
access it. 

G Group: in this category, a user may access data created by anyone 
in the groups the user belongs to. 

A All: in this category, a user may access any data on the system. 
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DATABASE OPERATIONS SCREEN ACCESS 


Group Project System 



Read 

Write 

Read 

Write 

Read 

Write 

Contributors 

A 

X 

A 

X 

A 

A 

Experiments 

G 

G 

G 

G 

G 

G 

Institution 

A 

X 

A 

X 

A 

A 

Software Trouble Report 

G 

G 

G 

G 

G 

G 

Inhouse Software 

G 

G 

G 

G 

G 

G 

Vendor Software 

A 

A 

A 

A 

A 

A 

Hardware Unit 

G 

G 

G 

G 

G 

G 

Documentation 

A 

A 

A 

A ! 

A 

A 

Personal Keywords 

O 

O 

O 

o 

O 

O 

Archive Medium 

A 

A 

A 

A 

A 

A 

Data Archive 

G 

O 

G 

O 

G 

O 

Software Archive 

G 

O 

G 

O 

G 

O 

Processed Data 

G 

O 

G 

O 

G 

O 

Raw Data 

G 

O 

G 

O 

G 

O 

Technical Papers 

A 

A 

A 

A 

A 

A 

Notebook 

G 

O 

G 

O 

G 

O 
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CONTRIBUTOR DATABASE OPERATION 


Contributors arc AIRLAB personnel who use the ADAMS system to support 
their work. Only system managers can add, update or delete a contributor data- 
base record. Project leaders and group members can browse all contributor 
records on the system but cannot add, update or delete contributor records. 

Data in the Contributor screen is manipulated using the browse, add, update, and 
delete functions described in Chapter 3 — Manipulating the ADAMS Database. 

A sample Contributor screen is presented in the figure on the opposite page. 
Contributor screen fields are described in the table below. 


CONTRIBUTOR SCREEN FIELDS 


Reid Name 

Mandatory? 

Description 

Username: 

Yes 

Single line input 

Name: 

Yes 

Single line input 

Address: 

No 

Multi-line input 

Phone: 

No 

Single line input 

Job Title: 

No 

Single line input 

Job Desc: 

No 

Multi-line input 
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ADAMS 

Browse Contributor 


Username: 

JAS 

Name: 

John Smith 

Address: 

Anywhere 

U.S.A. 

Phone: 

(555)-lll-0000 

Job Utle: 

Computer sdentist 

Job Desc.: 

Conduct research on phase one of AIRLAB 
experiment - flight control system prototype 


<7/8> = Print 

<0> = Exit Screen 

<-> = Prev Screen 

<FF2> = Help 

< Enter > = Do 

<,> = Next Screen 


(B_CONT _AS) 
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EXPERIMENT DATABASE OPERATION 


Experiments are the AIRLAB experiments that a group is working on under a 
project. System managers, project leaders and group members can add new 
records and browse, update, and delete any experiment records that were created 
by someone in the group(s) they belong to. 

Data in the Experiment screen is manipulated using the browse, add, update and 
delete functions described in Chapter 3 - Manipulating the ADAMS Database. 

A sample Experiment screen is presented in the figure on the opposite page. 
Experiment screen fields are described in the table below. 


EXPERIMENT SCREEN FIELDS 


Field Name 

Mandatory? 

Description 

Ident: 

Automatically generated 

Integer record identifier 

Group: 

Yes 

Must enter group that already exists 

Name: 

Yes 

Single line input 

Desc: 

No 

Multi-line input 

Username: 

No 

Paging region 

Inst: 

No 

Paging region 

esehhi 

No 

Paging region 

Sw Name: 

No 

Paging region 

Ver: 

No 

Paging region 
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ADAMS 

Browse Experiment 


Ident: 

Name: 

Desc: 

Username: 

Inst: 

Keyword: 
Sw Name: 


3 Group: CONTROL 

SW RELATED HW ERRORS 
Investigates flight control software errors 
which result from hardware malfunctions 

[ J AS ] 

[contract Research Inc j 

SOFTWARE 

HARDWARE 

[FLIGHT I Ver: 1.0 



<0> = Exit Scr 

<7/8> = Print 

<-> = Prev Scr 

<Enter> = Do 

<PF2> = Help 

<,> = Next Scr 
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INSTITUTION DATABASE OPERATION 


Institutions are organizations that are conducting experiments at AIRLAB. Only 
system managers can add, update or delete an institution database record. Pro- 
ject leaders and users can browse all institution records on the system but cannot 
add, update or delete any institution records. 

Data in the Institution screen is manipulated using the browse, add, update and 
delete functions described in Chapter 3 - Manipulating the ADAMS Database. 

A sample Institution screen is presented in the figure on the opposite page. Insti- 
tution screen fields are described in the table below. 


INSTITUTION SCREEN FIELDS 


Held Name 



Inst. Id: 

Yes 


Name: 

Yes 

Multi-line input 

Dept: 

No 


Address: 

No 


Phone: 

No 



No 



No 

Paging region 
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ADAMS 

Browse Institution 


Inst Id: CRI 

Name: Contract Research Inc 

Dept: Software Development 

Address: Anywhere 

U.S.A. 


Phone: (lll)-555-0000 

Purpose: To coordinate research on phase one of AIRLAB 

experiment - flight control software 


Keyword: 


SOFTWARE 

FLIGHT 


<7/8> = Print <„> = Next Screen <-> = Prev Screen 

<PF2> = Help <Enter> = Do <0> = Exit Screen 


(BJNST^AS) 
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SOFTWARE/HARDWARE DATABASE OPERATION 
SOFTWARE TROUBLE REPORT SCREEN 

Software Trouble Report describes software bugs and fixes to them. System 
managers, project leaders, and group members can add new records and browse, 
update, and delete any software trouble reports that were created by someone in 
the group(s) they belong to. 

Data in the Software Trouble Report screen is manipulated using the browse, 
add, update and delete functions described in Chapter 3 - Manipulating the ADAMS 
Database. 

A sample Software Trouble Report screen is presented in the figure on the oppo- 
site page. Software Trouble Report screen fields are described in the table below. 


SOFTWARE TROUBLE REPORT FIELDS 


Held Name 

Mandatory? 

Description 

Name: 

Yes 

Single line input 

Version: 

Yes 


Status: 

Yes 

Single line input 

Ident: 

Automatically generated 

Integer record identifier 

Group: 

Yes 

Hvl IW JiiH-i «-M Mil 

Username: 

Automatically generated 

Who is making report 

Machine: 

Automatically generated 

What machine logged on to 

E5S5S3H 

Automatically generated 

Date reported 

Fix Date: 

No 

Single line input 

ESSSSMi 

Yes 

Scrolling region (1st box) 

Fix Text 

No 

Scrolling region (2nd box) 
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ADAMS 

Browse Software Trouble Report 


Name: FLIGHT I 

Version: 1.0 

Status: FIXED 

Ident: 3 


Group: AXIS 

Username: JAS 

Machine: 1 


Rpt Date: 06/02/85 

Fix Date: 06/03/85 


Fatal error in Pilot Interface I screen. Blows up in “dologon” and 
“dologoff ’ if user types more than one line of information. Error 
messages are “error during get” (pascal) and “terminator not seen”. 


Fixed. Changed to screen. 


<Up> = Prev line <Enter> = Do <7/8> = Print <-> = Prev Scr. 

<Down> = Next line <0> = Exit Scr. <PF2> = Help <,> = Next Scr. 



(B_S W_TR_AS) J 
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SOFTWARE/HARDWARE DATABASE OPERATION 
INHOUSE SOFTWARE 


Inhouse Software describes software written at AIRLAB to support AIRLAB 
experiments. System managers, project leaders, and group members can add new 
records and browse, update, and delete any inhouse software record that has 
been created by someone in the group(s) they belong to. 

Data in the Inhouse Software screen is manipulated using the browse, add, 
update and delete functions described in Chapter 3 - Manipulating the ADAMS 
Database. 

A sample Inhouse Software screen is presented in the figure on the opposite page. 
Inhouse Software screens fields are described in the table below. 


INHOUSE SOFTWARE REPORT FIELDS 


Field Name 


Description 

Name: 

Yes 

Single line input 

Version: 

Yes 

Single line input 

Online? 

No 

Yes or no answer 

Group: 

Yes 

Must enter existing group(s) 

Date: 

No 

Single line input 

Author: 

No 

Single line input 
Person who wrote software. 

Expert: 

No 

Single line input. Someone who knows 
a lot about using software. 

Desc: 

No 

Multi-line input 

Add. Info: 

No 

Multi-line input 


No 

Paging region 

Location 

No 

Scrolling region 
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ADAMS 

Browse Inhouse Software 


Name: 

Version: 

Author: 

Expert: 

Desc: 


Add Info: 


Flight Interface Group: 

1.2 Online? Y Date: 

JAS John A. Smith 

JSD Jane S. Doe 

Provides an easy method for creating an input 
file to be used with FLIGHT I 

A user’s guide is available 
Ask JSD 


AXIS 

06/01/85 


Keywords: I FLIGHT 


VAX/VMS operating system 


<Up> = Prev Line <Enter> = Do <7/8> = Print <-> = Prev Scr. 

<Down> = Next Line <0> = Exit Scr. <PF2> = Help <,> = Next Scr. 


(BJN_SW_AS) 


« 
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SOFTWARE/HARDWARE DATABASE OPERATION 
VENDOR SOFTWARE SCREEN 

Vendor Software describes software purchased from non-AIRLAB vendors to 
support AIRLAB experiments. System managers, project leaders, and group 
members can add a new record and browse, update, and delete any vendor 
software record that was created by someone in the group(s) they belong to. 

Data in the Vendor Software screen is manipulated using the browse, add, update 
and delete functions described in Chapter 3 - Manipulating the ADAMS Database. 

A sample Vendor Software screen is presented in the figure on the opposite page. 
Vendor Software screen fields are described in the table below. 


VENDOR SOFTWARE FIELDS 


Field Name 


Description 

Name: 

Yes 


Vendor: 

Yes 

Multi-line input 

Version: 

Yes 


Date: 

No 

Single line input 

Expert: 

No 

Single line input. Someone who knows 
a lot about using software. 

Desc: 

No 

Multi-line input 

Add Info: 

No 

Multi-line input 


No 

Paging region 

Location: 

No 

Scrolling region 
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\ 

ADAMS 

Browse Vendor Software 


Name: 

MASS11 

Version: 

4-B 

Vendor: 

DEC 

Date: 

06/01/85 

Expert: 

JSD Jane S. Doe 



Desc: 

Word processing package 



Add Info: 

Call by Mil 



Keywords: 

[massu ] 




AIRS 


<Up> = Prev Line <Enter> = Do <7/8> = Print <-> = Prev Scr. 

<Down> = Next Line <0> = Exit Scr. <PF2> = Help <,> = Next Scr. 



(B_VEND_SW_AS) 
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SOFTWARE/HARDWARE UNIT DATABASE OPERATION 
HARDWARE UNIT SCREEN 


Hardware Units describes hardware that supports AIRLAB experiments. The 
hardware may be owned by AIRLAB or brought in by other companies for 
research projects. Any ADAMS user may add a Hardware Unit record to the 
database, and browse, update, or delete records created by anyone in the groups 
he belongs to. 

Data in the Hardware Unit screen is manipulated using the browse, add, update 
and delete functions described in Chapter 3 — Manipulating The ADAMS Database. 

A sample Hardware Unit screen is presented in the figure on the opposite page. 
Hardware Unit screen fields are described in the table below. 


HARDWARE UNIT SCREEN FIELDS 


Field Name 


Description 

Inven No: 

Yes 

Single line input. 
Integers only. 

Machine: 

No 


Room: 

Yes 


Building: 

Yes 


Group: 

Yes 

EB3ESSE33S35SB5I 

Hw Name: 

Yes 

Single line input 

Serial No: 

No 

Single line input 

Manufact. : 

No 

Single line input 

Model No: 

No 


Status: 

No 

Single line input 

Cost: 

No 

Single line input 

Comments: 

No 

Multi-line input 


No 

Paging region 
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ADAMS 

Browse Hardware Unit 


Inventory No: 

71850 

Hw Name: 

VAX 

Machine: 

1 

Serial No: 

A543210ZB9 

Room/Building: 

123/1220 

Manfact.: 

DEC 

Group: 

AXIS 

Model No: 

117780 

Status: 

Installed 



Cost: 

$40000.00 



Comments: 




Keywords: 

[VAX 

1 



<7/8> = Print <0> = Exit Scr <-> = Prev Scr <Up> = Prev Entry 

<PF2> = Help <Enter> = Do <,> = Next Scr <Down> = Next Entry 
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DOCUMENTATION DATABASE OPERATION 


Documentation consists of all user manuals, guides, and other media used during 
an AIRLAB project. This includes inhouse and vendor-supplied documentation. 
System managers, project leaders, and group members can add a new record and 
browse, update, and delete any documentation record that was created by any 
ADAMS user. 

Data in the Documentation screen is manipulated using the browse, add, update 
and delete functions described in Chapter 3 — Manipulating The ADAMS Database. 

A sample Documentation screen is presented in the figure on the opposite page. 
Documentation screen fields are described in the table below. 


DOCUMENTATION SCREEN FIELDS 


Field Name 


Description 

Doc Id: 

Yes 

Formatted input. 2 characters - 
3 numerals. 

Vendor: 

Yes 

Single line input 

Subject: 

No 

Single line input 

Part Num: 

No 

Single line input 

Hw/Sw: 

No 

Single line input 
Valid inputs - H or S 

Title: 

No 

Multi-line input 

Remarks: 

No 

Multi-line input 


Yes 

Paging region 
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ADAMS 

Browse Documentation 


Doc Id: AA-111 

Vendor: DEC 

Subject: VAX/VMS 

Part Num: AA-Z502A-TE 

Hw/Sw: S 

Title: VAX/VMS Run-Time Library Routines Reference Manual 


Remarks: Maynard, MA 


Keywords: 


VAX 

SOFTWARE 


< Enter > = Do 

<FF2> = Help 

<-> = Prev Record 

<0> = Exit Screen 

<7/8> = Print 

<,> = Next Record 


(BJX)C_AS)/ 
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PERSONAL KEYWORDS DATABASE OPERATION 


Personal Keywords are identifiers defined by the individual ADAMS user to tag 
and later retrieve database records. All ADAMS users can access only those per- 
sonal keywords they’ve defined. Group keywords are defined by the project 
leader and can be used by anyone in the group. 

Data in the Personal Keywords screen is manipulated using the browse, add, 
update and delete functions described in Chapter 3 — Manipulating The ADAMS 
Database. 

A sample Personal Keywords screen is presented in the figure on the opposite 
page. Personal Keywords screen fields are described in the table below. 


PERSONAL KEYWORDS SCREEN FIELDS 


Field Name 

Mandatory? 


Username: 

Automatically generated 

ESSffiHBEl 


Yes 
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ARCHIVE DATABASE OPERATION 
ARCHIVE MEDIUM SCREEN 


The Archive Medium screen contains information about tapes, disks, and so on 
which are available at AIRLAB for archiving files. All ADAMS users can add a 
new record and browse, update, and delete any existing archive medium record. 

Data in the Archive Medium screen is manipulated using the browse, add, update 
and delete functions described in Chapter 3 — Manipulating The ADAMS Database. 

A sample Archive Medium screen is presented in the figure on the opposite page. 
Archive Medium screen fields are described in the table below. 


ARCHIVE MEDIUM SCREEN FIELDS 


Field Name 


Description 

Archive ID: 

Yes 

Storage identifier. Single line input. 

MSEEBE3M 

Yes 

Type of storage medium. Single-line input. 

Room/Building: 

Yes 

Building/Room (integers). Single line input. 

Comments: 

No 

Multi-line input 
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r 

ADAMS 


Browse Archive Medium 

Archive ED: 

T123A 

Archive Type: 

1600 BPI TAPE 

Room/Building: 

123/1220 

Comments: 

Software Failure Data 


<Enter> = Do <PF2> = Help <-> = Prev Record 

<0> = Exit Screen <7/8> = Print <,> = Next Record 
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ARCHIVE DATABASE OPERATION 
DATA ARCHIVE SCREEN 


The Data Archive screen tells what data has been archived by which AIRLAB 
contributors. Users may archive their own data (see the AIRLAB User Guide for 
more information). ADAMS users may browse any Data Archive records created 
by members of their group and add new records to the database, but can only 
delete and update records they’ve personally created. 

Data in the Data Archive screen is manipulated using the browse, add, update 
and delete functions described in Chapter 3 — Manipulating The ADAMS Database. 

A sample Data Archive screen is presented in the figure on the opposite page. 
Data Archive screen fields are described in the table below. 


DATA ARCHIVE SCREEN FIELDS 


Field Name 

Mandatory? 

Description 

Date: 

Automatically generated 

Single line field 

Username: 

Automatically generated 

Single line field 

Group: 

Yes 

Must be existing group(s) 

Table? 

Yes 

Yes if Oracle table, no otherwise 

Data Name: 

Yes 


Archive ID: 

Yes 

Storage identifier. Single line input 


Yes 

Type of storage medium. Single line input 

Comments: 

No 

Multi-line input 


No 

Paging region 
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ADAMS 

Browse Data Archive 


Date: 

06/01/85:17:05:03 Keywords: j FLIGHT 

Username: 

JSD 1 

Group: 

AXIS 

Table: 

N 

Data Name: 

SOFTWARE FAILURE DATA 

Archive ID: 

T123A 

Archive Type: 

1600 BPI TAPE 

Comments: 

There is an estimated 20 megabytes of 
software failure time for experiment A of 
Flight I. 


<Enter> = Do <PF2> = Help <-> 

<0> = Exit Screen <7/8> = Print <,> 


= Prev Record 
= Next Record 


(BJDATA^AR^AS) 
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ARCHIVE DATABASE OPERATION 
SOFTWARE ARCHIVE SCREEN 


The Software Data Archive screen tells what AIRLAB software has been archived 
and on which devices. ADAMS users may browse any Software Archive records 
created by members of their group and add new records to the database, but can 
only delete and update records they’ve personally created. 

Data in the Software Archive screen is manipulated using the browse, add, 
update and delete functions described in Chapter 3 — Manipulating The ADAMS 
Database. 

A sample Software Archive screen is presented in the figure on the opposite page. 
Software Archive screen fields are described in the table below. 


SOFTWARE ARCHIVE SCREEN FIELDS 


Field Name 

Mandatory? 

Description 

Date: 

Automatically generated 

Single line field 

Username: 

Automatically generated 

Single line field 

Group: 

Yes 

Must enter existing group(s) 

Sw Name: 

Yes 


Sw Version: 

Yes 

Single line input 

Archive Id: 

Yes 



Yes 


Comments: 

No 

Multi-line input 
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ADAMS 

Browse Software Archive 


Date: 

Username: 

Group: 

Sw Name: 
Sw Version: 
Archive ID: 
Archive Type: 


06/01/85:170503 

JAS 

AXIS 

Flight Interface 

1.0 

T123B 

1600 BPI Tape 


Co mm ents: 


<Enter> = Do <PF2> = Help <-> = Prev Record 

<0> = Exit Screen <7/8> = Print <,> = Next Record 


(B_SW _ARC _AS) 
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DATA DATABASE OPERATION 
PROCESSED DATA SCREEN 


The Processed Data screen provides information about processed AIRLAB experi- 
mental data and the analyses applied to the data. ADAMS users may read any 
Processed Data records created by members of their group and add new records 
to the database, but can only delete and update records they’ve personally 
created. 

Data in the Processed Data screen is manipulated using the browse, add, update 
and delete functions described in Chapter 3 — Manipulating The ADAMS Database. 

A sample Processed Data screen is presented in the figure on the opposite page. 
Processed Data screen fields are described in the table below. 


PROCESSED DATA SCREEN FIELDS 


Field Name 

Mandatory? 

Description 

Data Name: 

Yes 

Single line input 

Format: 

No 

Physical structure of data. 
Single line input. 

Location: 

No 

Single line input 

Username: 

Automatically generated 

Single line field 

Time: 

Automatically Generated 

Single line field 

Group: 

Yes 


Rec Count: 

No 

Single line input 

Table? 

Yes 

Yes if Oracle table, no otherwise. 

Archived? 

Yes 

Yes or no response 

Desc: 

No 

Multi-line input 

Analysis: 

No 

Analysis performed on data. 
Single line input. 


No 

Paging region 

Software: 

Yes 

Scrolling region. 

Tab between name and version. 
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ADAMS 

Browse Processed Data 


Data Name: 
Format: 
Location: 
Rec Count: 
Desc: 


Analysis: 


SOFTWARE ERROR RATES Username: 

Matrix of Error Rates Time: 

RATES. FOR Group: 

5M Table? N Archived? N 
Matrix contains error rates 
Rows indicate modules, Columns are Fault IDs 
Run Flight Interface 


JSD 

06/15/85:14:23:59 

AXIS 


Keywords: 


SOFTWARE 
ERROR RATES 


l::DISK$SHEMP:[JSD.EXP]RATES.FOR 


1.5 


<Up> = Prev line <Enter> = Do <7/8> = Print <-> = Prev Scr. 

<Down> = Next line <0> = Exit Scr. <PF2> = Help <,> = Next Scr. 


(B_P_DATA_ AS) 
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DATA DATABASE OPERATION 
RAW DATA SCREEN 


The Raw Data screen provides information about unprocessed AIRLAB experi- 
mental data. ADAMS users may read any Raw Data records created by members 
of their group and add new records to the database, but can only delete and 
update records they’ve personally created. 

Data in the Raw Data screen is manipulated using the browse, add, update and 
delete functions described in Chapter 3 — Manipulating The ADAMS Database. 

A sample Raw Data screen is presented in the figure on the opposite page. Raw 
Data screen fields are described in the table below. 


RAW DATA SCREEN FIELDS 


Field Name 

Mandatory? 

Description 

Data Name: 

Yes 


Format: 

No 

Physical structure of data. Single line input. 

Location: 

No 


Username: 

Automatically generated 

Single line field 

Time: 

Automatically generated 

Single line field 

Group: 

Yes 

Must be existing group(s) 

Rec Count: 

No 

Single line input 

Table? 

Yes 

Yes if Oracle table, no otherwise. 

Archived? 

Yes 

Yes or no response 

Desc: 

No 

Multi-line input 


No 

Paging region 

Software: 

Yes 

Scrolling region. 

Tab between name and version. 
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TECHNICAL PAPER DATABASE OPERATION 


Technical Paper describes literature references used by AIRLAB project members 
during an experiment and publications generated during the course of an experi- 
ment. All ADAMS users can browse, add, update and delete any Technical 
Paper record on the system. 

Data in the Technical Paper screen is manipulated using the browse, add, update 
and delete functions described in Chapter 3 — Manipulating The ADAMS Database. 

A sample Technical Paper screen is presented in the figure on the opposite page. 
Technical Paper screen fields are described in the table below. 

Note: papers entered on this screen may include papers written by ADAMS users 
during an AIRLAB experiment as well as papers written by authors outside AIR- 
LAB. To enter an ADAMS user in the Author field, type the author’s username 
and press <RET>. ADAMS will fill in the rest of the field with the author’s full 
name. To enter an author who is not an ADAMS user, press <TAB> to get past 
the username subsection of the Author paging region and enter the author’s full 
name. 


TECHNICAL PAPER SCREEN FIELDS 


Reid Name 


Description 

Tide: 

No 

Multi-line input 

Archive Loc.: 

No 

Where journal etc. is stored. Single line input. 

Publ. Citation: 

No 

Name of journal etc. Single line input. 

Length: 

No 

Single line input 

Author: 

No 

Paging region 

Institution: 

No 

Paging region 


No 

Paging region 

Abstract: 

No 

Scrolling region 
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ADAMS 

Browse Technical Paper 


Title: Experiments with Hardware Related Software Errors: 

New Results 


Archive Loc.: 

Library 



Publ. Citation: 

FTCS16 


Length: 10 

Author: 

[ JSD 

J. S. Doe | 


Institution: 

f CRI 

1 Keyword: 

f FLIGHT 


This paper describes the results of a series of reliability testing 
experiments using flight management software. The experiment investigates 
the frequency with which software errors result from hardware malfunctions in 
the pilot interface. 


<Up> = Prev line <Enter> = Do <7/8> = Print <-> = Prev Scr. 
<Down> = Next line <0> = E/rit Scr. <PF2> = Help <,> = Next Scr. 


(B_TECH_P_AS) 
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NOTEBOOK DATABASE OPERATION 


Notebook is an online experimenter’s or engineer’s notebook that contains per- 
sonal and project notes written during an AIRLAB experiment. ADAMS users 
may browse any Notebook records created by members of their group and add 
new records to the database, but can only delete and update records they’ve per- 
sonally created. 

Data in the Notebook screen is manipulated using the browse, add, update and 
delete functions described in Chapter 3 — Manipulating The ADAMS Database. 
You can enter the Add Notebook action screen from VMS by typing note at the 
prompt. After entering the note, exit the Add Notebook screen to return to 
VMS. 

A sample Notebook screen is presented in the figure on the opposite page. Note- 
book screen fields are described in the table below. 


NOTEBOOK SCREEN FIELDS 


Field Name 

Mandatory? 

Description 

Username: 

Automatically generated 

Single line field 

Group: 

Automatically generated 

Set to PERSONAL; can be redefined. 
Single line input. 

Ident: 

Automatically generated 

Single line field 

Date: 

Automatically generated 

Single line field 

ESEEESli 

No 

Paging region 

Text 

No 

Scrolling region 
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ADAMS 

Browse Notebook Entry 


Username: 

Group: 

Ident: 

Date: 


For application section, need to develop a complete example showing process 
of generating an interpreter: 

1. Gr amm ar: extend BEXP to include functions on boolean expressions 

2. Rewrite rules: general OR, binary AND 

3. Consistency: check rewrite rules, identifying intersections of LHS 


<Up> = Prev line <Enter> = Do <7/8> = Print <-> = Prev Scr. 

<Down> = Next line <0> = Exit Scr. <PF2> = Help <,> = Next Scr. 


(B_NOTE_AS) 



JAS Keyword: [FLIGHT 

AXIS 1 

1 

06/17/85:15:24:31 
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Chapter 6 — ADAMS Maintenance Operations 



WHAT ARE THE MAINTENANCE OPERATIONS 


The Maintenance Operations menu contains several actions screens and the fol- 
lowing 4 submenus. 

1. Security Database 

2. Relations Database 

3. Logon/off Information 

4. Configuration Management 

The Maintenance Operations action screens are: 

Access Level Selected from a submenu under Security Database. 

Usernames and their ADAMS security levels (S, P, 
or G). 

Project Access Selected from a submenu under Security Database. 

Usernames and the projects they are permitted to 
access. 

Selected from a submenu under Relations Database. 
Group keywords associated with project groups. 

Selected from a submenu under Relations Database. 
Usernames and the project groups they are associ- 
ated with. 

Project Selected from a submenu under Relations Database. 

Projects and their member groups. 

Logon Selected from a submenu under Logoff/on Informa- 

tion. Information entered when users first logon to 
the ADAMS system. 

Logoff Selected from a submenu under Logoff/on Informa- 

tion. Information entered when users logoff from 
the ADAMS system. 

Software Configuration Selected from a submenu under Configuration 

Management. Software installed or removed from 
AIRLAB’s computer system. 

Hardware Configuration Selected from a submenu under Configuration 

Management. Hardware installed or removed from 
AIRLAB’s computer system. 

Note: Users with group level permission can access only Logon/off Information 
under Maintenance Operations. 

The Maintenance Operations menu structure is illustrated as an inverted tree in 
Appendix B, which shows the first few levels of the branching system labeled with 
screen mnemonics. Each ADAMS screen has a mnemonic associated with it. 


Keyword 

User 
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Appendix C provides a list of screen mnemonics and their definitions arranged 
alphabetically for reference. 

The general format and contents of menu, action, and report screens are dis- 
cussed in Chapter 2. Database record manipulation is discussed in Chapter 3. The 
manipulation of single line fields, multi-line fields, paging regions and scrolling 
regions is discussed in the section How to Input Data on ADAMS Action Screens in 
Chapter 3. 
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Unused Page 
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SECURITY LEVELS AND ADAMS MAINTENANCE 


The access permitted to ADAMS users with system (S), project (P), and group 
(G) privileges for the various Maintenance Operation screens is described in the 
table on the opposite page. Each account permission column in the table is 
divided into Read and Write subcolumns. Read permission means a user can 
browse an entry in the screen, but not add new entries or change or delete exist- 
ing entries. Write permission means a user can browse, add, update, and delete 
entries stored in the system. 

Four character codes indicate the amount of access permitted to a screen: 

X No access is permitted to this category. 

O Owner: only the username that created the data in this category may 
access it. 

G Group: in this category, a user may access data created by anyone in 
the groups the user belongs to. 

A All: in this category, a user may access any data on the system. 


ADAMS Maintenance Operations, p. 6-4 



MAINTENANCE OPERATIONS SCREEN ACCESS 


Group Project System 



Read 

Write 

Read 

Write 

Read 

Write 

Access Level 

X 

X 

X 

X 

A 

A 


X 

X 

X 

X 

A 

A 

Keyword 

X 

X 

G 

G 

A 

A 

User 

X 

X 

G 

G 

A 

A 

Project 

X 

X 

G 

G 

A 

A 

Logon 

A 

A 

A 

A 

A 

A 

Logoff 

A 

A 

A 

A 

A 

A 

Software Configuration 

X 

A 

A 

A 

A 

A 

Hardware Configuration 

X 

A 

A 

A 

A 

A 
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SECURITY MAINTENANCE OPERATION 
ACCESS LEVEL SCREEN 


The Access Level screen associates ADAMS usernames with access permission 
level codes (S, P, or G). Only system managers can read and write any access 
level records. 

Data in the Access Level screen is manipulated using the browse, add, update 
and delete functions described in Chapter 3 — Manipulating The ADAMS Database. 

A sample Access Level screen is presented in the figure on the opposite page. 
Access Level screen fields are described in the table below. 


ACCESS LEVEL SCREEN FIELDS 


Field Name 

Mandatory? 

Description 

Username: 

Yes 

Single line input 

Access: 

Yes 

Single line input 
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ADAMS 

Browse User Access Level 
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SECURITY MAINTENANCE OPERATION 
PROJECT ACCESS SCREEN 


The Project Access screen associates ADAMS usernames with ADAMS projects. 
Only system managers can read and write any project access record. 

Data in the Project Access screen is manipulated using the browse, add, update 
and delete functions described in Chapter 3 — Manipulating The ADAMS Database. 

A sample Project Access screen is presented in the figure on the opposite page. 
Project Access screen fields are described in the table below. 


PROJECT ACCESS SCREEN FIELDS 


Field Name 


Description 

Project: 

Yes 

Enter existing project, then user. Single line input. 

Username: 

Yes 
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ADAMS 

Browse Project Access 


Project 

Username 

SW RELATED HW ERRORS 

JAS 

SW RELATED HW ERRORS 

JSD 


<Enter> = Do 

<PF2> 

= Help 

<Up> 

= Prev Record 

<0> = Exit Screen 

<7/8> 

= Print 

<Down> 

= Next Record 


(SEC_B_PRJ_ACC_LVL) 
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RELATIONS MAINTENANCE OPERATION 
KEYWORD SCREEN 


The Keyword screen associates keywords with individual project groups. Infor- 
mation in this category cannot be accessed by users with group permission (G). 
Project leaders (P) can create or delete keywords for groups under their projects. 
System managers (S) can access any keyword on the system. 

Data in the Keyword screen is manipulated using the browse, add, update and 
delete functions described in Chapter 3 — Manipulating The ADAMS Database. 

A sample Keyword screen is presented in the figure on the opposite page. Key- 
word screen fields are described in the table below. 


KEYWORD SCREEN FIELDS 


Reid Name 


Description 

Group: 

Yes 

Enter existing group 


Yes 


Comments: 

No 

Multi-line input 
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ADAMS 

Browse Keyword/Group Relation 


Group: CONTROL 

Keyword: SOFTWARE 

Comments: Flight Interface Version 1.0 has been archived 








RELATIONS MAINTENANCE OPERATION 

USER SCREEN 


The User screen associates ADAMS usernames with individual project groups. 
Information in this category cannot be accessed by users with group permission 
(G). Project leaders (P) can associate usernames with groups under their projects; 
system managers (S) can access any usemame/group relation on the system. 

Data in the User screen is manipulated using the browse, add, update and delete 
functions described in Chapter 3 — Manipulating The ADAMS Database. 

A sample User screen is presented in the figure on the opposite page. User screen 
fields are described in the table below. 


USER SCREEN FIELDS 


Reid Name 


Description 

Group: 

Yes 

Enter existing group 

Username: 

Yes 
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RELATIONS MAINTENANCE OPERATION 
PROJECT SCREEN 


The Project screen associates ADAMS projects with individual groups. Informa- 
tion in this category cannot be accessed by users with group permission (G). Pro- 
ject leaders (P) can define groups and associate them with their projects and 
delete their groups; system managers (S) can access any group/project relation on 
the system. 

Data in the Project screen is manipulated using the browse, add, update and 
delete functions described in Chapter 3 — Manipulating The ADAMS Database. 

A sample Project screen is presented in the figure on the opposite page. Project 
screen fields are described in the table below. 


PROJECT SCREEN FIELDS 


Field Name 


mmasm 

Project: 

Yes 


Group: 

Yes 
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ADAMS 

Browse Project/Group Relation 


Project 

Group 

SW RELATED HW ERRORS 

AXIS 

SW RELATED HW ERRORS 

CONTROL 


< Enter > = Do 

<PF2> = Help 

<Up> 

= Prev Record 

<0> = Exit Screen 

<7/8> = Print 

<Down> 

= Next Record 


(REL _B .PROJECT _AS) 
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LOGON/OFF INFORMATION MAINTENANCE OPERATION 

LOGON SCREEN 

The Logon screen contains information identifying the start of each ADAMS ses- 
sion, and an optional Purpose field describing the reason for the session. All 
ADAMS users can access any Logon record in the database. 

Data in the Logon screen is manipulated using the browse, add, update and 
delete functions described in Chapter 3 — Manipulating The ADAMS Database. 

A sample Logon screen is presented in the figure on the opposite page. Logon 
screen fields are described in the table below. 


LOGON SCREEN FIELDS 


Field Name 

Mandatory? 


Username: 

Automatically Generated 


Machine: 

Automatically Generated 


Time: 

Automatically Generated 



No 
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ADAMS 

Browse Logon Info 


Username: 

Machine: 

Tune: 

Purpose: 


JAS 

1 

06/14/85:12:30:01 

To add notes on AIRLAB experiments 


<7/8> = Print 

<0> 

= Exit Screen 

<-> = Prev Screen 

<PF2> = Help 

< Enter > 

= Do 

<»> = Next Screen 


(B_LOGON_AS) 
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LOGON/OFF INFORMATION MAINTENANCE OPERATION 

LOGOFF SCREEN 

The Logoff screen contains information identifying the end of each ADAMS ses- 
sion, and an optional Remarks field for comments on the session just ended. Any 
ADAMS user can access any Logoff record in the database. 

Data in the Logoff screen is manipulated using the browse, add, update and 
delete functions described in Chapter 3 — Manipulating The ADAMS Database. 

A sample Logoff screen is presented in the figure on the opposite page. Logoff 
screen fields are described in the table below. 


LOGOFF SCREEN FIELDS 


Field Name 

Mandatory? 


Username: 

Automatically Generated 

EP33CBEI; 

Machine: 

Automatically Generated 

E&39X3E1 

Time: 

Automatically Generated 

E&9ES5E1 

Remarks: 

No 

DiSKSIII 
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CONFIGURATION MANAGEMENT 
SOFTWARE CONFIGURATION 


Software Configuration provides information regarding the installation or removal 
of software on AIRLAB’s computer system. Any user can browse any Software 
Configuration record. Project leaders and system managers can add, update and 
delete all records in this subcategory of Maintenance Operations. 

Data in the Software Configuration screen is manipulated using the browse, add, 
update and delete functions described in Chapter 3 — Manipulating the ADAMS 
Database. 

A sample Software Configuration screen is presented in the figure on the opposite 
page. Software Configuration screen fields are described in the table below. 


SOFTWARE CONFIGURATION 


Field Name 

Mandatory? 

Description 

Sw Name: 

Yes 

Single line input 

Sw Ver: 

Yes 

Single line input 

Date Submitted: 

No 

Single line input 


No 

Single line input 

Date Performed: 

No 



No 

Single line input 

Removed From: 

Automatically generated 

Set to 0; can be redefined. 

Single line input; numeric values only. 

Installed In: 

Automatically generated 

Set to 0; can be redefined. 

Single line input; numeric values only. 

Comments: 

No 

Multi-line input 

Statement of Work: 

No 

Scrolling region 
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c 

ADAMS 



Browse Software Configuration 


Sw Name: 

Flight Interface 



Sw Ver: 

1.2 



Date Submitted: 

03/15/85 

Submitted By: 

JSD 

Date Performed: 

03/29/85 

Performed By: 

JAT 

Removed From: 

0 

Installed In: 

1 

Comments: 

Up and running 




Flight Interface has been installed on airl. 


< Enter > = Do <7/8> = Print <-> = Prev Screen 

<0> = Exit Screen <PF2> = Help <,> = Next Screen 


(B_SW_CON_AS)^ 
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CONFIGURATION MANAGEMENT 
HARDWARE CONFIGURATION 


Hardware configuration provides information regarding the installation or remo- 
val of hardware on AIRLAB’s computer system. All users can browse any 
Hardware Configuration record. Project leaders and system managers can add, 
update and delete any record in this subcategory of Maintenance Operations. 

Data in the Software Configuration screen is manipulated using the browse, add, 
update and delete functions described in Chapter 3 — Manipulating the ADAMS 
Database. 

A sample Hardware Configuration screen is presented in the figure on the oppo- 
site page. Hardware Configuration screen fields are described in the table below. 


HARDWARE CONFIGURATION 


Field Name 

Mandatory? 

Description 

Inventory No: 

Yes 


Date Submitted: 

No 



No 

Single line input 

Date Performed: 

No 

Single line input 

Performed By: 

No 

Single line input 

Removed From: 

Automatically generated 

Set to 0; can be redefined. 

Single line input; numeric values only. 

Installed In: 

Automatically generated 

Set to 0; can be redefined. 

Single line input; numeric values only. 

Comments: 

No 

Multi-line input 

Statement of Work: 

No 

Scrolling region 
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ADAMS 

Browse Hardware Configuration 


Inventory No: 71850 
Date Submitted: 05/21/85 
Date Performed: 06/19/85 


Submitted By: JSD 

Performed By: JAT 


Removed From: 0 


Installed In: 3 


Comments: Disk 


No problems with installation. 


<Enter> = Do <7/8> = Print <-> = Prev Screen 

<0> = Exit Screen <PF2> = Help <,> = Next Screen 


(B _HW_CON _AS) 
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Appendix A — Status and Error Messages 



STATUS AND ERROR MESSAGES 


The following list of status and error messages is sorted alphabetically except the 

first message in the list which may begin with several different field names. 

• x xxx x field must have a value 

Meaning: This field of a scrolling/paging region must have a value. 

Action: Enter an appropriate value for the region. 

• Duplicate key value in table 

Meaning: You entered a key value (e.g., username or data name) that 

already exists in the data table. 

Action: Enter a new value and try again. 

• Error opening file username, tmp. 

Meaning: You do not have write access to the current VAX/VMS file 

directory and cannot perform this function. 

Action: Restart ADAMS under a different directory that you have 

write access to. 

. • Error opening menu file x xxxx 

Meaning: This is an ADAMS internal error. 

Action: The list of valid menus could not be found because the 

ADAMS logical names are not properly set up. See the sys- 
tem manager to correct this problem. 

• Error trying to enter EDT 

Meaning: There was an error while creating a subprocess to run EDT. 

Action: You do not have write access to the current VAX/VMS file 

directory. Change directories and try again. 
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• Invalid character "x" in field 


Meaning: You entered an invalid character in this field. 

Action: Examine input for error and reenter. 

• Invalid function key 

Meaning: The key typed is not valid in this context. 

Action: Select a different function. 

• Invalid group name, try again 

Meaning: The group name entered is not assigned to you. 

Action: Enter a group you belong to; use <PF2> keypad on Group 

field to list groups. 

• Invalid keyword, hit Gold-Enter to make it a key 

Meaning: You entered a personal keyword that does not exist. 

Action: <PFl>KEYPAD<Enter>KEYPAD will add it to your personal key- 

word list. 

• Invalid keyword, try again 

Meaning: You entered a keyword that does not exist for this group. 

Action: Enter an existing keyword; use <PF2> keypad on keyword 

field to list keywords. 

• Keyword exists, try again 

Meaning: You tried to add a keyword that already exists. 

Action: Enter a new keyword; use <PF2> on keyword field to list 

keywords. 
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• No x xx x x values left 


Meaning: You tried to delete an entry from a scrolling/paging region 

that did not exist. 

Action: Select a different ADAMS function. 

• No groups found 

Meaning: You do not belong to any valid groups. 

Action: Ask your project leader or system manager to add your user- 

name to the appropriate groups. 

• No keywords found 

Meaning: There are no keywords for the group you have chosen. 

Action: The project leader will define group keywords as needed. 

• No more records 

Meaning: There are no more records left in the list. 

Action: Use another search template to retrieve more records. 

• No next form 

Meaning: You are at the last record retrieved and tried to advance. 

Action: If the record desired is not in the set retrieved, change the 

search template and try again. 

• No next page in form 

Meaning: You tried to go to the next field at the end of the screen. 

Action: Back up to the correct field with the appropriate cursor 

movement co mm and. 
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• No next x xxxx page 


Meaning: You tried to go the the next page of a scrolling/paging region 

and there is not one. 

Action: If information is missing, add it to the database record. 

• No previous form 

Meaning: You are at the first record retrieved and tried to back up. 

Action: If the record desired is not in the set retrieved, change the 

search template and try again. 

• No previous xx x xx page 

Meaning: You tried to go to the previous page of a scrolling/paging 

region and there is not one. 

Action: If information is missing, add it to the database record. 

• No previous page in form 

Meaning: You tried to go to the previous field from the first field in a 

screen. 

Action: Advance to the correct field with the appropriate cursor 

movement command. 


• No records found 


Meaning: There are no records matching the current selection criteria. 

Action: Enter a different search template and try again. 


• String not found 


Meaning: 

Action: 


You searched for a non-existent string in a scrolling text 
region. 

Enter a string that is in the text region. 
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• That project does not exist, try again 

Meaning: You entered a project name that does not exist. 

Action: Enter an existing project. Contact the ADAMS system 

manager for project names. 

• This action invalid for this group 

Meaning: You tried to enter a keyword for a group with the 

<PF1> keypad < ENTER> keypad sequence. 

Action: Only project leaders can add group keywords. 

• You cannot modify that group, try again 

Meaning: You entered a group name that you do not have modify 

access to. 

Action: Enter a group name you can modify; use <PF2>keypad on 

the Group field to list groups. 

• You cannot modify that project, try again 

Meaning: You entered a project that you do not have modify access to. 

Action: Enter a project you can modify. Contact the ADAMS sys- 

tem manager for project names. 

• You do not have access to that function 

Meaning: You tried to access a security protected function and do not 

have the proper level of security clearance. 

Action: Contact your project leader or system manager to determine 

your security clearance level. 
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Appendix B — The ADAMS Menu Tree Structure 



THE ADAMS MENU TREE STRUCTURE 


The ADAMS menu system is structured like a tree’s branching root system, with 
the main menu at the trunk’s base and the individual report screens at the tips of 
the roots. The structure is illustrated in this Appendix, which shows the first few 
levels of the branching system labeled with screen mnemonics. 
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Appendix C — Screen Mnemonic Names 



SCREEN MNEMONIC NAMES 


This Appendix provides a list of screen mnemonics and their definitions 
arranged alphabetically for quick reference. 


A_ARC_MED_AS 

A_ARC_MN 

A_CON_AS 

A^DATA_AR_AS 

AJDATA.MN 

A_DOC_AS 

A_EXP_AS 

A_HW_AS 

A_HW_CON _AS 

AJNST^AS 

A_IN_SW _AS 

A_NOTE_AS 

A^P_DATA_AS 

AJ»ERS_KEY_AS 

A_R_DATA_AS 

A_SW_ARC_AS 

A_SW_CON_AS 

A^_SW_HW_MN 

A_SW_TR_AS 

AJTECH_P_AS 

A_VEND_SW_AS 

ARC_MN 

B_ARC_MED_AS 

B_ARC_MN 

B _DATA _AK-AS 

B_DATA_MN 

B_DOC_AS 

B JEXP _AS 

B_HW_AS 

B_HW_CON_AS 

B_INST_AS 

BJN.SW^AS 

B ^LOGOFF _MN 

B_LOGON_AS 

B_NOTE_AS 

B_P_DATA^AS 

B_PERS_KEY_AS 

B_R^D AT A_ AS 

B_SW_ARC_AS 


Add Archive Medium 
Add Archive 
Add Contributor 
Add Data Archive 
Add Data 

Add Documentation 

Add Experiments 

Add Hardware 

Add Hardware Configuration 

Add Institution 

Add Inhouse Software 

Add Notebook 

Add Processed Data 

Add Personal Keyword 

Add Raw Data 

Add Software Archive 

Add Software Configuration 

Add Software/Hardware 

Add Software Trouble Report 

Add Technical Paper 

Add Vendor Software 

Archive Menu 

Browse Archive Medium 

Browse Archive 

Browse Data Archive 

Browse Data 

Browse Documentation 

Browse Experiments 

Browse Hardware 

Browse Hardware Configuration 

Browse Institution 

Browse Inhouse Software 

Browse Logoff 

Browse Logon 

Browse Notebook 

Browse Processed Data 

Browse Personal Keyword 

Browse Raw Data 

Browse Software Archive 
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B-SW_CON_AS 

B_SW_HW_MN 

B_SW_TFO\S 

B_TECH_P_AS 

B_VEND_SW_AS 

CON_MN 

CONT_MN 

D_ARC_MED_AS 

D_ARC_MN 

D_CON_AS 

D_DATA_AK_AS 

D_DATA_MN 

DATABASE.MN 

D_DOC_AS 

DJEXP_AS 

D_HW_AS 

D_HW_CON _AS 

D_INST_AS 

D_IN_SW_AS 

D_LOGOFF_MN 

D_LOGON_AS 

D _NOTE _AS 

D_P_DATA_AS 

D_PERS_KEY _AS 

d_r_data_as 

D_SW_ARC_AS 

D_SW_CON _AS 

D_SW_HW_MN 

D_SW_TR_AS 

D_TECH_P _AS 

D_VEND_SW_AS 

DATA.MN 

DOC_MN 

EXP_MN 

INST.MN 

LOG_MN 

LOGOFF_MN 

LOGON_MN 

MAINT_MN 

NOTE_MN 

PERS _KEY_MN 

REL_A_KEY_AS 

REL_A_PROJECT_AS 

REL_A_U SER_AS 


Browse Software Configuration 
Browse Software/Hardware 
Browse Software Trouble Report 
Browse Technical Paper 
Browse Vendor Software 
Configuration Management Menu 
Contributors Menu 
Delete Archive Medium 
Delete Archive 
Delete Contributor 
Delete Data Archive 
Delete Data 

Database Operations Menu 
Delete Documentation 
Delete Experiments 
Delete Hardware 
Delete Hardware Configuration 
Delete Institution 
Delete Inhouse Software 
Delete Logoff 
Delete Logon 
Delete Notebook 
Delete Processed Data 
Delete Personal Keyword 
Delete Raw Data 
Delete Software Archive 
Delete Software Configuration 
Delete Software/Hardware 
Delete Software Trouble Report 
Delete Technical Paper 
Delete Vendor Software 
Data Menu 
Documentation Menu 
Experiments Menu 
Institutions Menu 
Logon/off Menu 
Logoff Menu 
Logon Menu 
Maintenance Menu 
Notebook Menu 
Personal Keyword Menu 
Relation Add Keyword 
Relation Add Project 
Relation Add User 
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REL_B_KEY_AS 

REL_B_PROJECT-AS 

REL_B_USER-AS 

REL_D_KEY_AS 

REL_D_PROJECT_AS 

REL_D_USER_AS 

REL_KEY _MN 

REL_PROJECT_MN 

REL_U_KEY_AS 

REL_U_PROJECT_AS 

REL_USER_MN 

REL_U_USER^AS 

RELATE _MN 

SEC_A_ACC _LVL _AS 

SEC_ACC_LVL3IN 

SEC_A U _PRJ_ACC_AS 

SEC_B_ACC_LVL_AS 

SEC_B_PRJ_ACC_AS 

SEC_D_ACC_LVL_AS 

SEC_D_PRJ_ACC_AS 

SEC_PRJ_ACC_MN 

SEC_U_ACC_LVL_AS 

SEC_U_PRJ_ACC_AS 

SECURE_MN 

SW_HW_MN 

TECH_P_MN 

U_ARC_MED_AS 

U_ARC_MN 

U_CON_AS 

U_DATA_AR^AS 

U_DATA_MN 

U_DOC_AS 

U_EXP_AS 

U_HW_AS 

U_HW_CON_AS 

U_INST_AS 

U_IN_SW_AS 

U_NOTE_AS 

U_P_DATA_AS 

U_PERS_KEY_AS 

U_R_DATA^_AS 

U_SW_ARC_AS 

U_SW_CON_AS 

U_SW _JfW _MN 


Relation Browse Keyword 
Relation Browse Project 
Relation Browse User 
Relation Delete Keyword 
Relation Delete Project 
Relation Delete User 
Relation Keyword Menu 
Relation Project Menu 
Relation Update Keyword 
Relation Update Project 
Relation User Menu 
Relation Update User 
Relations Menu 
Security Add Access Level 
Security Access Level 
Security Add Project Access 
Security Browse Access Level 
Security Browse Project Access 
Security Delete Access Level 
Security Delete Project Access 
Security Project Acess 
Security Update Access Level 
Security Update Project Access 
Security Menu 
Software/Hardware Menu 
Technical Paper Menu 
Update Archive Medium 
Update Archive 
Update Contributor 
Update Data Archive 
Update Data 
Update Documentation 
Update Experiments 
Update Hardware 
Update Hardware Configuration 
Update Institution 
Update Inhouse Software 
Update Notebook 
Update Processed Data 
Update Personal Keyword 
Update Raw Data 
Update Software Archive 
Update Software Configuration 
Update Software/Hardware 
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U_SW_TR-AS 

U_TECH_P_AS 

U_VEND_SW - AS 


Update Software Trouble Report 
Update Technical Paper 
Update Vendor Software 
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Appendix D — An ADAMS Usage Example 



APPENDIX D 

AN ADAMS USAGE EXAMPLE 


Purpose/Background 

The following example illustrates the use of ADAMS to record and retrieve 
information about experimental research being conducted by the Research Trian- 
gle Institute using AIRLAB as a part of a NASA-LaRC sponsored program in 
software reliability. The goal of this program, which is being pursued by the 
Fault Tolerant Systems Branch of NASA - LaRC under the technical direction of 
G.E. Migneault, is to find a means of credibly performing reliability evaluations 
of flight control software. The program entails the funding of academic studies, 
data gathering experiments, and includes the conduct of in-house software relia- 
bility analyses. 

The example contained in this Appendix depicts an organization of project 
data chosen by the project members. This organization permits rapid retrieval of 
information related to the different software reliability experiments presently 
being conducted. AIRLAB users who are working on other projects may prefer a 
different organization, that is, one which is tailored to suit their needs. 


Using ADAMS 

Defining the Software Reliability Research Project 

Defining the Software Reliability Research project using ADAMS involved 
establishing a framework which organizes the research activities and specifying a 
set of project keywords fundamental to retrieving key information associated with 
the project. We first chose to decompose the project into groups which 
correspond to the distinct software reliability experiments being conducted as the 
most suitable framework for org anizing information about the multiple experi- 
mental activities. Second, to facilitate co mmuni cation between project members 
working wi thin a group and between groups with s imil ar goals, we established 
group memberships and defined a standard set of keywords. The project groups, 
group members, and group keywords are described in the following sections. 

Project Groups 

The software reliability research project currently has four experimental 
efforts for which AIRLAB is a critical resource. These are: 

(1) Automated repetitive run testing of the Launch Interceptor Condition 
Software to collect data on 100 replications 
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(2) Fault Interaction Experiments using the N- VERSION CONTROLLER on 
Systems 1,2,4,5, 6,7,8 and 9. 

(3) Reliability Testing of the Pitch Axis Control Software on System 4. 

(4) Development of the Viking Lander Software Specification on System 4. 

Each of these activities has been established by the Project Leader as a group 
under the Software Reliability Research project in the ADAMS Relations data 
base using the Add Project Action Screen. This data base entry is shown in Fig- 
ure 1. 
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<Enter> = Do <PF2> = Help <Up> = Prev Record 

<0> = Exit Screen <7/8> = Print <Down> = Next Record 


(REL_B J’ROJECT _AS) 


Figure 1. Software Reliability Research Project Groups 
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Group Me mbers 

Different members of the RTI staff are associated with one or more of 
the group activities within the Software Reliability Research project. To iden- 
tify which staff members are associated with each group, the Add User Ac- 
tion Screen was used by the project leader to specify group members in the 
ADAMS Relations database. Figure 2 shows the data in the first scrolling re- 
gion of the Group Relation database entry. 

Group Keywords 

To make information about the software reliability project easily accessible to 
all project members, we decided to define a set of standard project keywords 
which are applicable to each group activity in the project and which are used in 
the same manner by each group member. Our choice of keywords reflects the 
type of information being communicated. The consistent use of these keywords 
must be enforced if the project is to benefit from their use. The use of multiple 
keywords when entering activity information provides multiple paths to data base 
entries containing more than one type of information. 

The following list describes the keywords which have presently been defined by 
the Project Leader in the Relations database using the Add Keyword Action 
Screen. 

DESCRIPTION - index for descriptions of the research activities being conducted 
(An example is the first entry for an experiment as shown in Figure 3. This entry 
describes the experimental goals and contains the Description keyword). 

DIRECTORIES - index for all directories associated with the research activity 

PROBLEMS - index for all entries which are related to problems encountered dur- 
ing the conduct of the research. 

REPORTS - index for all system and technical reports associated with the research 

TOOLS - index for all hardware and software tool tools associated with the con- 
duct of the research 

STATUS - index for both personal and project notes which contain information 
about the status of the research 

PROB[n] - index for the nth problem in the series of implementations of software 
problems being studied as a part of the continuing experiments in software relia- 
bility 
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ADAMS 

Browse User/Group Relation 


Group Username 


AUTOSIM 

GEM 

AUTOSIM 

JRD 

AUTOSIM 

RCB 

AUTOSIM 

SEM 

INTEXP 

GEM 

INTEXP 

JRD 

INTEXP 

RCB 

INTEXP 

SEM 

PITCH AXIS 

GEM 

PITCH AXIS 

HO 

PITCH AXIS 

JRD 


< Enter > = Do 

<PF2> 

= Help 

<Up> 

= Prev Record 

<0> = Exit Screen 

<7/8> 

= Print 

<Down> 

= Next Record 


17 records found. (REL_B_USER^AS) 



Figure 2. Project Group Members 
RAW DATA - index for the raw data associated with the research 

PROCESSED DATA - index for the processed data associated with the research 

Note that the chosen Software Reliability Project keywords intersect the different 
types of information requested when m aking an ADAMS entry. This intersection 
was intentionally chosen to provide cross-indexing between ADAMS experiment 
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ADAMS 

Browse Experiment 


Ident: 1 Group: AUTOSIM 

Name: AUTOMATED REPETITIVE RUN TESTING 

Desc: The purpose of the experiment is to gather failure data 

from 100 replications of repetitive run testing of the three 
implementations of the LIC software. 


Username: 


GEM 

JLP 


Inst: 


NASA-LARC 

RTI 


Keyword: 


DESCRIPTION 

PROB1 


Sw Name: I AUTOSIM 


Ver: 1.5 ] 


<0> = Exit Scr 

<7/8> 

= Print 

<-> = Prev Scr 

<Enter> = Do 

<PF2> 

= Help 

<,> = Next Scr 


1 record found. 


(B_EXP_AS) 


Figure 3. An Experiment Entry with a "Description” Keyword 
entries, software entries, and data entries. 

Documenting the Research Activities 

The Software Reliability Research activities conducted as a part of the project 
are documented in several ADAMS database entries. The following sections 
describe a sample of entries related to the AUTOSIM group under the Software 
Reliability Research project. 
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Experiment Entry 

Figure 3 shows an experiment activity example . It was entered using the 
Add Experiment Action Screen of the ADAMS Database Menu. This entry 
describes the AUTOSIM experiment. Other entries which contain informa- 
tion about the experiment were made using the Add Notebook Screen with 
AUTOSIM as the group field entry. 


ADAMS 

Browse Notebook Entry 


Username: JRD 

Group: AUTOSIM 

Ident: 3 

Date: 07/12/85:15:51:14 


Keywords: 


RAW DATA 
STATUS 


The data collection effort has been halted for two reasons: 

1. The results of the investigation of the non-observation of fault 7 are 
pending. 

2. System 3 has been experiencing system disk problems which result in loss of 
data due to the method of restarting AUTOSIM. 


<Up> = Prev line <Enter> = Do <7/8> = Print <-> = Prev Scr. 
<Down> = Next line <0> = Exit Scr. <PF2> = Help < t > = Next Scr. 



record found. 



Figure 4. A Project Notebook Entry 
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Notebook Entry 

In collecting the 100 replications of data for the AUTOSIM experiment, the 
system disk on System 3 experienced several failures during the second and third 
weeks of June. In addition to the experiment entry shown in Figure 4 which indi- 
cated a stopped status, a personal note was made to record the problems with the 
system. This personal notebook entry is depicted in Figure 5. 


ADAMS 

Browse Notebook Entry 


Username: JRD 

Group: Personal 

Ident: 1 

Date: 06/24/85:14:18:24 


Keywords: 


AUTOSIM 

PROBLEMS 


AUTOSIM is currently running on 3::DISK$LARRY:[SIMTEST.3.SIM.PROBl]. 
SYSTEM 3 has been unreliable as there are problems with I/O on the system 
disk. SEM has currently stopped running AUTOSIM during the day. 

GEM has been notified. 



Figure 5. A Related Personal Notebook Entry 
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Figure 6. An Experimental Software Entry 
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Documentation Entry 

A technical report was written to document the AUTOSIM tool and to 
fulfill the contract reporting requirements. The corresponding documentation 
entry is shown in Figure 7. Technical papers associated with the experiment 
were documented using the Add Technical Paper Action Screen. 



Doc Id: 

AD-001 

Vendor: 

RTI 

Subject: 

AUTOSIM DOCUMENTATION 

Part Num: 

NAS1-16489;N0.24 

Hw/Sw: 

S 

Title: 

AUTOSIM: A Repetitive Run Modeling Test Tool by J.R. 
Dunham and S.E. McBride 

Remarks: 

The report documents the AUTOSIM tool using the 
Jackson Schematic Logic Diagrams. 

Keywords: 

[autosim J 


<Enter> = Do 

<PF2> = Help 

<-> = Prev Record 

<0> = Exit Screen 

<7/8> = Print 

<,> = Next Record 


1 record found. 



(B_DOC_AS) 


Figure 7. A Documentation Entry 
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Data Entries 

There are three types of data entries which can be made using ADAMS. 
These entries contain information about raw data, processed data, and ar- 
chived data. In making these entries, we used AUTOSIM Group Keywords 
to establish links between the data entries. 

Figure 8 contains an example of a RAW DATA entry which describes failure 
data that was generated during repetitive run testing of the LIC problem prior to 
installation of AUTOSIM. It was recorded as a part of the AUTOSIM project 
since the data was compared to that recorded during the AUTOSIM testing of the 
LIC software as part of the validation of the AUTOSIM tool. 

This raw data was subsequently been archived and the archive information 
was recorded using the Add Archive Action Screen of ADAMS. 

The raw data was also processed and the actual failure rates retained in a 
tabular form for later analysis. The location of the processed data was recorded 
using the Add Processed Data Action Screen. 

Figures 8, 9, and 10 show the Raw Data, Archived Data, and Process Data 
entries for the manual repetitive run replications respectively. 
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ADAMS 

Browse Raw Data 


Data Name: 
Format: 
Location: 


SIM. DAT Username: 

SEE NASA CR- 172553 Tune: 

3::DISK$LARRY :[SIMTEST.3.SIM.FROBl] Group: 


JRD 

06/25/85:15:15:46 

AUTOSIM 


Rec Count: 692 Table? N Archived? Y 

Desc: Contains LIC failure data prior to AUTOSIM. Archive name = 

LIC1. Failure time tables in 3::DISK$LARRY:[JRD.DATA]. 


Keywords: 


AUTOSIM 

PROB1 


AUTOSIM 


1.5 


<Up> = Prev line <Enter> = Do <7/8> = Print <-> = Prev Scr. 

<Down> = Next line <0> = Exit Scr. <PF2> = Help <,> = Next Scr. 


1 record found. 


(B_R_DATA_AS)y 


Figure 8. A Raw Data Entry 
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ADAMS 

Browse Data Archive 


Date: 06/26/85:17:4031 

Username: JRD 

Group: AUTOSIM 


Table: 
Data Name: 
Archive ID: 
Archive Type: 


N 

UC1 

AUTOSIM. LIC1 
1600 BPI Tape 


Comments: The data archived is a result of the installation of 

AUTOSIM - It contains the LIC data from the manual 
runs executed prior to AUTOSIM installation 2/06/85. 


<Enter> = Do 

<PF2> = Help 

<-> = Prev Record 

<0> = Exit Screen 

<7/8> = Print 

<,> = Next Record 


1 record found. (B_DATA_AR^_AS) 



Figure 9. An Archived Data Entry 
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ADAMS 

Browse Data Archive 


Date: 

06/26/85:17:40*31 

Username: 

JRD 

Group: 

AUTOSIM 

Table: 

N 

Data Name: 

UC1 

Archive ID: 

AUTOSIM. LIC1 

Archive Type: 

1600 BPI Tape 

Comments: 

The data archived is a result of the installation of 
AUTOSIM - It contains the LIC data from the manual 
runs executed prior to AUTOSIM installation 2/06/85. 


< Enter > = Do 

<PF2> = Help 

<-> = Prev Record 

<0> = Exit Screen 

<7/8> = Print 

<,> = Next Record 


1 record found. (B_DATA^AR_AS) 



Figure 9. An Archived Data Entry 
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Glossary 



GLOSSARY OF ADAMS TERMS 


Access Level: Associates ADAMS usernames with access permission level codes 
(S, P, or G). The Access Level screen is discussed in Chapter 6. 

account: Sometimes called a VAX/VMS username or user logon. You must have 
a valid AIRLAB account on VAX/VMS to use ADAMS. ADAMS and 
VAX/VMS are discussed m Chapter 2. 

action screen: Used to browse, add, update and delete database records. Action 
screens are discussed in Chapter 2. 

ADAMS: The AIRLAB Data Management System is an online environment that 
supports research at AIRLAB. 

Add function: Creates new ADAMS database records and adds them to the data- 
base. The Add function is discussed in Chapter 3. 

AIR1: The DECnet node name of AIRLAB’s Digital Equipment Corporation 
(DEC) VAX 11/780. Also called System 1. 

archive: Information that is not actively being used in an AIRLAB project. 
Archived information is usually stored on offline media (e.g., magnetic 
tapes). 

Archive Medium: Tapes, disks, etc. which are available at AIRLAB for archiving 
files. The Archive Medium screen is described in Chapter 5. 

arrow key: One of the four arrow keys on the terminal keyboard (up, down, left, 
right). The right and left arrow keys move the cursor right or left respec- 
tively on an action screen. The up and down arrow keys move the cursor in 
the scrolling and paging region on report screens. 

auto wrap: A feature provided in some computer systems that automatically 
wraps information being typed at a terminal onto the next line of text when 
the end of the terminal screen is reached. ADAMS does not support auto 
wrap. 

Browse function: Examines database records in a working set. Each report screen 
displayed represents a single database record. The Browse function is dis- 
cussed in Chapter 3. 
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bug: An error in the construction of a computer program (i.e., software) that 
results in a malfunction. Bugs in AIRLAB software are reported with the 
Software Trouble Report screen. 

case (upper/lower): Upper case letters (i.e., capital letters) are generated by 
pressing the <SHIFT> key while typing at the terminal keyboard. Some 
ADAMS data fields are all upper-case (e.g., keywords). Lower-case char- 
acters entered in these fields are automatically converted to upper-case. 

command: An instruction to a program like ADAMS or the VAX/VMS operating 
system to perform a function. Many ADAMS commands are executed by 
pressing a terminal keypad key. 

Contributor: AIRLAB researchers who use ADAMS to support their work. The 
Contributor screen is discussed in Chapter 5. 

cursor: A special character displayed on a terminal screen that indicates where 
text is currently being entered or the active field for ADAMS commands. 
The cursor is sometimes displayed as a small box, and sometimes as an 
underscore character. The cursor may or may not blink, depending on the 
terminal’s set up. 

data access: The process of retrieving, deleting, or modifying existing data 
records in the ADAMS database. Permission to access a given data record 
depends on the username’s security level and the type of data. ADAMS 
security is discussed in Chapters 2, 5, and 6. 

Data Archive: Tells what data has been archived by which AIRLAB contributors. 
The Data Archive screen is discussed in Chapter 5. 

data retrieval: The process of reading records from the ADAMS database and 
making them part of the active working set. Once data records are 
retrieved, they can be altered using the Update function or removed from 
the database using the Delete function. 

database: A collection of information stored on the computer’s disks. The 
ADAMS database can only be accessed through the ADAMS user interface. 
Access to individual data records is restricted by user, project, and group 
using the ADAMS security system (see Chapter 2). 

database function: Add, Update, Delete, and Browse are the only valid opera- 
tions that can be performed on ADAMS database records. These functions 
are described in Chapter 3. 
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Database Operation: A set of submenus under the ADAMS main menu for mani- 
pulating database records. Database Operation screens are described in 
Chapter 5 (see also Maintenance Operation). 

database record: An individual report screen or data item stored m the ADAMS 
database. One or more database records are retrieved from the database 
and made part of the working set by setting up a template to qualify the 
search (see also template). 

DEC: Digital Equipment Corporation, manufacturers of AIRLAB’s VAX 11/780 
computer and the VAX/VMS operating system. 

default value: Certain fields on ADAMS action screens are automatically assigned 
a standard (i.e., default) value that the user can override by typing another 
acceptable value in the field. 

Delete function: Removes existing ADAMS data records from the database. The 
Delete function is discussed in Chapter 3. 

device: Hardware associated with a computer system that performs one or more 
specialized functions (e.g., disk drives for storing data). 

diagnostic message: Information generated by a computer system like ADAMS 
that describes action taken in response to a command or warns of error con- 
ditions. 

directory: A special location under the VAX/VMS operating system where files 
are stored. File directories may have subdirectories under them; this is use- 
ful for separating data files by project or experiment. 

Documentation: User manuals, guides, and other media used during an AIRLAB 
project. The Documentation screen is discussed in Chapter 5. 

editor: An interactive computer program for creating and modifying text files. 
EDT is the most commonly used VAX/VMS editor. 

EDT: See editor. 

error condition: A fault in a computer system caused by bad data, incorrect user 
input, or internal errors that prevents the system from operating correctly 
(see also bug, fix, and diagnostic message). 

error message: See diagnostic message. 
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Experiment: A1RLAB experiments that a group is working on under a project. 
The Experiment screen is discussed in Chapter 5. 

field help: An ADAMS status message that describes the contents of a field on an 
action screen. The help command is described m Chapter 2. 

field name: The label associated with an ADAMS action screen field. Action 
screens and their fields are described in Chapters 5 and 5. 

field value: The data value associated with an ADAMS action or report screen 
field. A field value is usually displayed to the right of the field name, but 
this depends on the nature of the field (single line, multi-line, scrolling 
region, or paging region). 

file: Information stored on a disk (see also database). 

fix: Changes made to a computer system to repair a bug (see also bug). 

function: See Add function. Delete function, Update function, or Browse function. 

Gold key: The <FF1> key in the top row of the numeric keypad. Many keypad 
keys perform more than one function; alternate functions are selected by 
pressing the Gold key first. 

group keyword: An identifier group members can use to tag database records for 
later retrieval by members of their group. Group keywords are discussed in 
Chapter 6 (see also Keyword and Personal Keywords). 

group level: Security level that allows a user to create and access co mm on group 
data, use group keywords, and create and access personal data. Group level 
security is discussed in Chapter 2 (see also project level, system level). 

group member: A username that has been assigned to a group by a project leader 
or system manager. 

hardware: The physical components of a computer system, including devices (as 
opposed to the programs that run on the system: see also software). 

Hardware Configuration: Selected from a submenu under Configuration 

Management. Hardware installed or removed from AIRLAB’s computer 
system. 

Hardware Unit: Hardware that supports AIRLAB experiments. The Hardware 
Unit screen is discussed m Chapter 5. 


Glossary of ADAMS Terms, p. G-4 



ident: A numeric identifier field associated with certain types of ADAMS data- 
base records. An ident field value is automatically assigned to a newly 
created data record. 

Inhouse Software: Software written at AIRLAB to support experiments. The 
Inhouse Software screen is discussed in Chapter 5. 

insert mode: Used to insert information in the middle of an action screen field’s 
value. Insert mode is discussed in Chapter 3 (see also overstrike mode). 

Institution: Organizations that are conducting experiments at AIRLAB. The 
Institution screen is discussed in Chapter 5. 

interaction: The process of performing work at a computer terminal by typing 
commands at the keyboard and observing the system’s response on the ter- 
minal screen (see also invoke). 

interface: The part of a computer system that a user directly interacts with, 
including terminal screen displays, diagnostic messages, and all keyboard 
and keypad co mm ands. 

invoke: To call up a computer program or operating system function by typing a 
command at the terminal keyboard (see also interaction). 

key value: An ADAMS action screen field value that is used to select data 
records for retrieval (e.g., username or data name). 

keyboard: In the ADAMS User’s Guide, usually refers to the main part of the 
te rmin al keyboard (as opposed to the numeric keypad). 

keypad: The set of numeric keys, programmable function keys (PF), <Enter>, 
and punctuation keys to the right of the main part of the terminal keyboard. 

Keyword: The Keyword screen is discussed in Chapter 6. It associates keywords 
with individual project groups (see also group keyword and Personal Key- 
words). 

Logoff: Used as a verb to describe the process of terminating an interactive ses- 
sion on AIRLAB’s computers. The Logoff screen is described in Chapter 6. 
It contains information identifying the end of each ADAMS session. 

Logon: Used as a verb to describe the process of accessing AIRLAB’s computers 
and the ADAMS system. Occasionally used as a synonym for username (see 
also username). The Logon screen is described in Chapter 6. It contains 
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information identifying the start of each ADAMS session. 

main menu: The set of ADAMS options that first appears after the initial Logon 
screen. The ADAMS menu structure is diagrammed m Appendix B (see also 
menu, menu screen, and menu tree). 

Maintenance Operation: A set of submenus under the ADAMS main menu for 
manipulating database records related primarily to ADAMS maintenance 
and security functions. Maintenance Operation screens are described in 
Chapter 6 (see also Database Operation). 

mandatory: Describes an action screen field that must be filled out when creating 
a template for data record retrieval or entering a new data record (see also 
optional). Failure to supply a value for a mandatory action screen field will 
generate an error message. 

menu: A list of ADAMS command options displayed on the ter min al screen. An 
individual option is selected by typing its menu index (displayed next to the 
option name on the screen). ADAMS menu structure is diagrammed in 
Appendix B. 

menu-driven: Describes a user interface (like ADAMS) that provides menus and 
submenus for user interaction (see also menu). 

menu screen: An ADAMS screen that displays a menu of options (see also action 
screen and report screen). 

menu tree: Certain menu options display secondary menus when they’re selected. 
The overall branching structure of the ADAMS menu system resembles an 
inverted tree, with the main menu at the root. ADAMS menu structure is 
diagrammed in Appendix B. 

mnemonic: A short descriptive name associated with ADAMS menu and action 
screens. ADAMS screen mnemonics are listed alphabetically m Appendix C 
and on the ADAMS Quick Reference Card. 

modify permission: A username that can delete or update an existing ADAMS 
database record has modify permission for that record, (see also read per- 
mission and write permission). 

multi-line field: An ADAMS action or report screen field that has a single value 
that fits across multiple lines (see also single line field, scrolling region, and 
paging region). 
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Notebook: Online experimenter’s or engineer’s notebook that contains personal 
and project notes written during an experiment. The Notebook screen is dis- 
cussed in Chapter 5. Notes can also be created from any menu by pressing 
<.> keypad co mm and to move to the Notebook screen, or outside the 
ADAMS system with the note command under VAX/VMS. See Chapter 2 
for a discussion of ADAMS commands. 

online: A computer program, database, or data rile that is directly accessible to 
the computer user is said to be online (as contrasted with archived ). 

operating system: A set of programs that allow a number of users to share a 
computer’s hardware and software resources (see also VAX/VMS). 

operator: One or more special characters used to specify data record creation 
date limits for qualifying database retrieval. Search templates are discussed 
in Chapter 3. This term is also used to refer to a person who’s responsible 
for monitoring a running computer system, mounting user tapes, etc. 

optional: Describes an optional action screen field that can be filled out to qualify 
data record retrieval or entered on a new data record (see also mandatory). 

ORACLE: A database management system at AIRLAB. The ADAMS system 
uses ORACLE to maintain its database file, but the ORACLE transactions 
are hidden from the user. 

overstrike mode: Used to type over information already entered in an action 
screen field. Overstrike mode is discussed in Chapter 3 (see also insert 

mode). 

page: A single terminal screen or portion of a ter min al screen used for displaying 
data. Used as a verb, this term refers to the action of bringing up the next 
region of data for display on the screen. 

paging region: An ADAMS action or report screen field that contains one or two 
values surrounded by brackets. To enter a paging region, press <1>keypad; 
to page through the region, use the arrow keys. (See also single line field, 
multi-line field, and scrolling region.) 

password: A secret key used to access a VAX/VMS username. 

permission: See read permission, modify permission, and write permission. 

Personal Keywords: Identifiers defined by the individual ADAMS user to tag and 
later retrieve database records. The Personal Keywords screen is discussed 
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in Chapter 5 (see also Keyword and group keyword). 

privilege: Refers to the level of access a username has been granted to a subset of 
the ADAMS database. ADAMS security is discussed in Chapters 2, 5, and 6 
(see also data access, security validation, and group! project! system level). 

Processed Data: A data set resulting from the processing of raw data (e.g., sta- 
tistical analysis, data reduction). The Processed Data screen is discussed m 
Chapter 5. 

Project: Associates ADAMS projects with individual groups. The Project screen is 
discussed in Chapter 6. 

Project Access: Associates ADAMS usernames with ADAMS projects. The Pro- 
ject Access screen is discussed in Chapter 6. 

project leader: An ADAMS user who is responsible for one or more experiments 
under an AIRLAB project (see also system manager and group member). 

project level: Security level that allows a user to deactivate and reactivate pro- 
jects, define and undefine group keywords, and assign and deassign users to 
project groups. Project level security is discussed in Chapter 2 (see also 
group level, system level). 

prompt: A message printed on the terminal screen requesting user input (see also 
cursor and field name). 

qualified search: A limited retrieval of records from the ADAMS database based 
on a search template. Search templates are discussed in Chapter 3 (see also 
operator and template). 

Raw Data: Provides information about unprocessed AIRLAB experimental data. 
The Raw Data screen is discussed in Chapter 5. 

read permission: A username that can retrieve an existing ADAMS database 
record for browsing has read permission for that record (see also modify per- 
mission and write permission). 

record: See database record. 

regular keyboard: See keyboard and keypad. 

report screen: An ADAMS screen that displays a retrieved data record from the 
database (see also action screen and menu screen). 
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reverse video: A way of highlighting text on a DEC computer terminal screen by 
displaying it in a different color background. 

screen: See action screen, menu screen, or report screen. 

scrolling region: An ADAMS action or report screen field that contains one or 
more lines of text surrounded by a box (see also single line field, multi-line 
field, and paging region). 

security level: See group level, project level, or system level. 

security validation: The process that the ADAMS system goes through in check- 
ing to see if a user has permission to access a data record. ADAMS secu- 
rity is discussed in Chapters 2, 5, and 6 (see also data access and 
group/project/ system level). 

session: A complete period of VAX/VMS and/or ADAMS work from logon to 
logoff. 

shared database: A set of data that can be manipulated by several users simul- 
taneously. The ADAMS database is discussed in Chapter 2. 

single line field: An ADAMS action or report screen field that fits on a single line 
(see also multi-line field, scrolling region, and paging region ). 

software: The programs that run on a computer system (as opposed to the physi- 
cal components that make up the system (see also hardware). 

Software Archive: Tells what AIRLAB software has been archived and on which 
devices. The Software Archive screen is discussed in Chapter 5. 

Software Configuration: Selected from a submenu under Configuration Manage- 
ment. Software installed or removed from AIRLAB’s computer system. 

• 

Software Trouble Report: For reporting and viewing software bugs and fixes to 
them. The Software Trouble Report screen is discussed in Chapter 5. 

status message: See diagnostic message. 

storage media: Tapes, disks, or other devices used for storing data. See also 
Archive and Archive Medium. 

string: A data field that contains upper and/or lower case characters, numbers, 
and special characters (as opposed to purely numeric data). An address or 
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name would be an example of a string. 

submenu: A menu that appears as a result of choosing an option on another 
menu (see also menu and menu tree). 

System 1: Refers to AIRLAB’s DEC VAX 11/780 computer (see also AIR1). 

system level: Security level that allows a user to access any data in the ADAMS 
system and grant access to ADAMS to other users. System level security is 
discussed in Chapter 2 (see also group level , project level). 

system manager: An ADAMS user who is responsible for maintaining the 
ADAMS system, creating new projects, and validating new ADAMS users 
(see also project leader and group member). 

table (ORACLE): Entries in an ORACLE database that satisfy a specific rela- 
tion. See the ORACLE documentation for further information. 

Technical Paper: Describes literature references used and generated during an 
AIRLAB experiment. The Technical Paper screen is discussed in Chapter 5. 

template: An action screen whose fields are used to qualify a data record 
retrieval. Templates are discussed in Chapter 3 (see also operator and quali- 
fied search). 

tree: See menu tree. 

Update function: Modifies fields in existing ADAMS data records and replaces 
them in the database. The Update function is discussed m Chapter 3. 

User: A user is someone who uses a computer to support his/her research. The 
User screen is discussed in Chapter 6; it associates ADAMS usernames with 
individual project groups. 

user interface: See interface. 

username: An account name used to get access to AIRLAB’s VAX/VMS operat- 
ing system (see also account. Logon, and Logoff). 

validation: See security validation. 

VAX/VMS: The operating system (see also operating system) for AIRLAB’s DEC 
VAX 11/780 computer. 
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Vendor Software: Software purchased from non-AIRLAB vendors to support 
experiments. The Vendor Software screen is discussed in Chapter 5. 

working set: The ADAMS database records retrieved as a result of a qualified or 
unqualified search (see also qualified search , operator, and template). 

write permission: A username that can create a new ADAMS database record 
and add it to the database has write permission for that kind of record (see 
also modify permission and read permission ). 
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example of, 5-31 
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example of, 5-33 
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access to, 5-5, 5-32 
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Documentation 

definition of, 5-1, 5-20 
example of, 5-21 
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access to, 5-5, 5-20 
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to edit Notebook entries, 2-5 
Experiment 
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example of, 5-9 
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access to, 5-5, 5-8 
Field help, 1-3, 1-6 
Gold key, 3-3 
Gold function, 3-3 
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example of, 5-11 
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access to, 5-5, 5-10 
Jump, 2-8 
Keypad, 3-2, 3-3 
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example of, 6-19 
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access to, 6-5, 6-18 
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example of, 6-17 
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Main Menu help 
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Menu Tree, 1*3, 1-6 
Keypad Key, 1-3, 1-6 
Menu screen 

commands, 2-8 
definition of, 2-8 
example of, 2-9 
Mnemonic, 2-8 
Notebook 

definition of, 5-2, 5-36 
example of, 5-37 
field names, 5-36 
access to, 5-5, 5-36 

Online help (see Field help, Main menu help) 

Operators, 3-4 

Overstrike mode, 3-4 
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Personal Keywords 
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example of, 5-23 
field names, 5-22 
access to, 5-5, 5-22 
Project leader, 2-4 
Read permission, 5-4, 6-4 
Regular keyboard, 3-2 
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example of, 6-11 
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User screen 
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example of, 6-13 
field names, 6-12 
access to, 6-5, 6-12 
Project screen 
definition of, 6-1, 6-14 
example of, 6-15 
field names, 6-14 
access to, 6-5, 6-14 
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commands, 2-14 
definition of, 2-12, 2-14 
example of, 2-13, 2-15 
Scrolling region, 3-4 
Security 

character codes, 5-4, 6-4 
project/group, 2-4 
security levels, 2-6, 2-7 
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Security Maintenance Operation 
Access Level 
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example of, 6-7 
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access to, 6-5, 6-6 
Project Access 
definition of, 6-1, 6-8 
example of, 6-9 
field names, 6-8 
access to, 6-5, 6-8 
Software/Hardware Units 
Hardware screen 
definition of, 5-1, 5-18 
example of, 5-19 
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access to, 5-5, 5-18 
Inhouse Software screen 
definition of, 5-1, 5-14 
example of, 5-15 
field names, 5-14 
access to, 5-5, 5-14 
Software Trouble Report screen 
definition of, 5-1, 5-12 
example of, 5-13 
field names, 5-12 
access to, 5-5, 5-12 
Vendor Software screen 
definition of, 5-1, 5-16 
example of, 5-17 
field names, 5-16 
access to, 5-5, 5-16 
Special terminal keys, 14 
System 1,1-1 
System manager, 24 
Technical Paper 

definition of, 5-2, 5-34 
example of, 5-35 
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access to, 5-5, 5-34 
Template, 3-5 
To log off, 3-1, 4-14, 4-15 
To log on, 3-1, 4-1, 4-3 
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overstrike mode, 34 
insert mode, 34 
Update function, 3-8 
Valid groups, 34 
Write permission, 54, 64 
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